Re: OT: ISPs: Linux's role nowadays
On Thu, Feb 25, 2010 at 03:27:53PM +, Michal wrote: > On 25/02/2010 14:00, Chris Adams wrote: > > Once upon a time, Marcel Rieux said: > >> I was under the impression that, at most small ISPs, Linux had > >> replaced Unix and played a central role in making things work. But > >> today, I spoke to an ISP employee who told me that Linux was only used > >> for Web servers and that, for routing and firewalling, nobody escaped > >> companies Cisco and Juniper which provide "solutions" where part of > >> the software has been integrated into hardware for efficiency > >> purposes. > > > > Servers don't really make good routers. When you are talking about > > traditional low- to mid-speed telco circuits (T1, T3), there have never > > been good, well-supported, cost-effective solutions for connecting those > > directly to Linux systems for routing that could compete with a basic > > Juniper or Cisco (or Adtran or ...) on price and ease of use. > > > > When you start talking about SONET links (OC-3 and up), Linux AFAIK > > doesn't handle things like protected paths and the like, and then you > > also quickly pass the performance capability of commodity hardware. > > Newer WAN circuits are using Ethernet, but you need OAM (which Linux > > doesn't support) to properly manage them as a replacement for > > traditional telco circuits. > > > > "Real" routers (aka Juniper and Cisco) use hardware-based forwarding > > that can run at line rate for 1G, 10G, and 100G interfaces. > > > > Dynamic routing has always been pretty weak in Linux as well. I have a > > few systems running Quagga for various purposes, but it is not nearly as > > powerful and flexible as a "traditional" router. > > > > Now, Juniper routers all run FreeBSD, but that's only on the routing > > engine (where the management and routing daemons run), not the > > forwarding engine (where the actual packet forwarding takes place). > > Juniper wrote all their own routing, PPP management, etc. daemons from > > scratch. It is kind of funny when you spend $100K+ on a router that has > > a Celeron 850 CPU and a whopping 20G hard drive. :-) > > > > I have lots of Linux servers, a few other old Unix servers, and a couple > > of Linux firewalls, but all my routers are Juniper. I've been working > > for small ISPs for 14 years, and I've never really seen a time where I > > would try to push Linux into serious routing. It costs too much on the > > low end and can't handle the performance on the high end. > > > > People have had great success with OpenBSD on firewalls and routers with > lots of traffic and 10GB NIC's etc > Yeah.. Linux also does OK on this front. Recently there has been reports about pushing 70 - 80 Gbit/sec through a single desktop-class Linux box. Yes, you read it correctly. Also recently there has been reports of pushing 5+ Mpps through a single Linux box. You can do a lot of things with software routers nowadays. -- Pasi -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: OT: ISPs: Linux's role nowadays
On Fri, Feb 26, 2010 at 01:41:11PM -0800, Rick Stevens wrote: > On 02/26/2010 03:02 AM, Pasi Kärkkäinen wrote: > > On Thu, Feb 25, 2010 at 03:27:53PM +, Michal wrote: > >> On 25/02/2010 14:00, Chris Adams wrote: > >>> Once upon a time, Marcel Rieux said: > >>>> I was under the impression that, at most small ISPs, Linux had > >>>> replaced Unix and played a central role in making things work. But > >>>> today, I spoke to an ISP employee who told me that Linux was only used > >>>> for Web servers and that, for routing and firewalling, nobody escaped > >>>> companies Cisco and Juniper which provide "solutions" where part of > >>>> the software has been integrated into hardware for efficiency > >>>> purposes. > >>> > >>> Servers don't really make good routers. When you are talking about > >>> traditional low- to mid-speed telco circuits (T1, T3), there have never > >>> been good, well-supported, cost-effective solutions for connecting those > >>> directly to Linux systems for routing that could compete with a basic > >>> Juniper or Cisco (or Adtran or ...) on price and ease of use. > >>> > >>> When you start talking about SONET links (OC-3 and up), Linux AFAIK > >>> doesn't handle things like protected paths and the like, and then you > >>> also quickly pass the performance capability of commodity hardware. > >>> Newer WAN circuits are using Ethernet, but you need OAM (which Linux > >>> doesn't support) to properly manage them as a replacement for > >>> traditional telco circuits. > >>> > >>> "Real" routers (aka Juniper and Cisco) use hardware-based forwarding > >>> that can run at line rate for 1G, 10G, and 100G interfaces. > >>> > >>> Dynamic routing has always been pretty weak in Linux as well. I have a > >>> few systems running Quagga for various purposes, but it is not nearly as > >>> powerful and flexible as a "traditional" router. > >>> > >>> Now, Juniper routers all run FreeBSD, but that's only on the routing > >>> engine (where the management and routing daemons run), not the > >>> forwarding engine (where the actual packet forwarding takes place). > >>> Juniper wrote all their own routing, PPP management, etc. daemons from > >>> scratch. It is kind of funny when you spend $100K+ on a router that has > >>> a Celeron 850 CPU and a whopping 20G hard drive. :-) > >>> > >>> I have lots of Linux servers, a few other old Unix servers, and a couple > >>> of Linux firewalls, but all my routers are Juniper. I've been working > >>> for small ISPs for 14 years, and I've never really seen a time where I > >>> would try to push Linux into serious routing. It costs too much on the > >>> low end and can't handle the performance on the high end. > >>> > >> > >> People have had great success with OpenBSD on firewalls and routers with > >> lots of traffic and 10GB NIC's etc > > So long as the firewall doesn't have to handle too many rules and the > routing decisions are minimal. At those traffic levels, the system > would be swamped with interrupts anyway. I think there's some serious > measurement issues here. > > > Yeah.. Linux also does OK on this front. Recently there has been reports > > about pushing 70 - 80 Gbit/sec through a single desktop-class Linux box. > > Yes, you read it correctly. > > Well, THAT I don't buy. I've not seen a 100Gbps or 1Tbps PCI-slot > NIC. I suppose you could put in an adequate number of 10Gbps NICs in a > box...assuming you have enough slots, and I don't think the internal > bus on any desktop is capable of moving that kind of data that fast. > Not to mention the interrupt storm that'd ensue. > See here: http://groups.google.com/group/linux.kernel/browse_thread/thread/70e62d8a85cd3241 "We've achieved 70 Gbps aggregate unidirectional TCP performance from one P6T6 based system to another. We figured out in our case that we were being limited by the interconnect between the Intel X58 and Nvidia N200 chips. The first 2 PCIe 2.0 slots are directly off the Intel X58 and get the full 40 Gbps throughput from the dual-port Myricom 10-GigE NICs we have installed in them. But the other 3 PCIe 2.0 slots are on the Nvidia N200 chip, and I discovered through googling that the link between the X58 and N200 chips only operates at PCIe x16 _1.0_ speed, whic
Re: OT: ISPs: Linux's role nowadays
On Sat, Feb 27, 2010 at 11:08:38AM -0500, Marcel Rieux wrote: > On Sat, Feb 27, 2010 at 8:36 AM, Pasi Kärkkäinen wrote: > > Ooops! Maybe the discussion is not over :) > > I understand not much of this, so let me try to sum this up in a > know-nothing friendly way. > > They use nvidia multi gpu video cards for routing. Hence, they don't > face the interrupts problems so soon. > Uhm, no, they didn't use video cards. They used normal Asus P6T6 desktop motherboard, which has additional PCI-e slots on the Nvidia NF200 PCI Express fanout switch chip (which is connected to the Intel X58 chipset). > I suppose this is pretty experimental at this stage, though. How many > cores are they using? I believe the plans are for 64 in the near > future. > No, that was not experimental at all. In addition to the normal desktop motherboard they used Myrinet 10 Gbit PCI-E NICs. > Now, this is interesting... I believe. Good thing Huang pretends he's > not after Intel's skin :) > 10 Gbit throughput, over a single 10 Gbit link, between Linux boxes was possible already in 2008. -- Pasi -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Xen support
On Mon, Mar 29, 2010 at 11:56:14AM +0530, Onkar Mahajan wrote: >Hi am not able to boot Xen dom0. Is there any definitive guide for getting >xen working on fedora 12. > Fedora 12 has Xen hypervisor and tools included, but it doesn't ship dom0 capable kernel. See: http://fedoraproject.org/wiki/Features/XenPvopsDom0 There's unofficial rpm repository with xendom0 kernels available. Note that you also need to update to Xen 4.0.0 for the latest kernels to work! http://fedorapeople.org/~myoung/dom0/src/xen-4.0.0-0.6.rc8.fc12.src.rpm -- Pasi -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Xen support
On Mon, Mar 29, 2010 at 04:39:22AM -0300, Itamar Reis Peixoto wrote: > > There's unofficial rpm repository with xendom0 kernels available. > > > > Note that you also need to update to Xen 4.0.0 for the latest kernels to > > work! > > http://fedorapeople.org/~myoung/dom0/src/xen-4.0.0-0.6.rc8.fc12.src.rpm > > > > -- Pasi > > > why fedora xen-rpm was not upgraded to xen 4.0 ? > Because Xen 4.0.0 hasn't been released yet. There's ongoing to work to get Xen 4.0.0 rpms to rawhide/F13. -- Pasi -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Xen support
On Mon, Mar 29, 2010 at 02:25:01PM +0530, Onkar Mahajan wrote: >Any suggestions from where I can get Xen 4.0 ? >or should I try some previous release of xen which works ? > I just sent you the link to the rc8 src.rpm :) -rc9 here: http://fedorapeople.org/~myoung/dom0/src/xen-4.0.0-0.6.rc9.fc12.src.rpm And the upstream sources here: http://xenbits.xensource.com/xen-4.0-testing.hg -- Pasi >Regards, >Onkar > >On Mon, Mar 29, 2010 at 2:16 PM, Pasi Kärkkäinen <[1]pa...@iki.fi> wrote: > > On Mon, Mar 29, 2010 at 04:39:22AM -0300, Itamar Reis Peixoto wrote: > > > There's unofficial rpm repository with xendom0 kernels available. > > > > > > Note that you also need to update to Xen 4.0.0 for the latest > kernels to work! > > > > > [2]http://fedorapeople.org/~myoung/dom0/src/xen-4.0.0-0.6.rc8.fc12.src.rpm > > > > > > -- Pasi > > > > > > why fedora xen-rpm was not upgraded to xen 4.0 ? > > > > Because Xen 4.0.0 hasn't been released yet. > There's ongoing to work to get Xen 4.0.0 rpms to rawhide/F13. > -- Pasi > -- > users mailing list > [3]us...@lists.fedoraproject.org > To unsubscribe or change subscription options: > [4]https://admin.fedoraproject.org/mailman/listinfo/users > Guidelines: [5]http://fedoraproject.org/wiki/Mailing_list_guidelines > > References > >Visible links >1. mailto:pa...@iki.fi >2. > http://fedorapeople.org/%7Emyoung/dom0/src/xen-4.0.0-0.6.rc8.fc12.src.rpm >3. mailto:users@lists.fedoraproject.org >4. https://admin.fedoraproject.org/mailman/listinfo/users >5. http://fedoraproject.org/wiki/Mailing_list_guidelines > -- > users mailing list > users@lists.fedoraproject.org > To unsubscribe or change subscription options: > https://admin.fedoraproject.org/mailman/listinfo/users > Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Xen support
On Tue, Mar 30, 2010 at 06:42:53PM -0400, Bill Davidsen wrote: > Onkar Mahajan wrote: > > Thanks Pasi for your concern. > > > > I will try with Xen 4.0.0 and may be write a small How-to for beginners to > > follow. > > > As far as I know, Xen 4.0.0 and the latest release of 3.x.x require a PAE > CPU. > That means that some older hardware running xen will stop working if you > upgrade. > > I saw that in the xen list, if you write something for beginners it would be > a > good thing to mention. > Yes, for PV (paravirtual) guests Xen requires PAE on 32bit systems. I think it was Xen 3.3.0 that was the first version to require PAE. 32bit Xen HVM guests don't need to be PAE. -- Pasi -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: F12 and time keeping ....
On Tue, Jan 12, 2010 at 04:31:56PM +0800, Ed Greshko wrote: > Ed Greshko wrote: > > Oliver Falk wrote: > > > >> Hi Ed! > >> > >> On 01/12/2010 08:23 AM, Ed Greshko wrote: > >> > >> > >>> At first I thought this was a VMware workstation issue. But now it > >>> points more to F12. > >>> > >>> > >> [ ... ] > >> > >> > >>> Is anyone having similar issues with time on F12? Part of the reason I > >>> noticed this was looking at the email headers generated from this list. > >>> The time of the servers jumps forward and then backward in time. But, > >>> since it by minutes maybe those servers just don't use ntp to keep > >>> sync > >>> > >>> > >> Try adding this to your kernel params (/etc/grub.conf): > >> > >> notsc divider=10 > >> > >> > > Just tried that to no avail. > > > > > In case some folks are unfamiliar with the phrase "to no avail"...it > means it didn't help. (My wife, a non-native English speaker, insists I > should be clearer :-) ) > "Timekeeping best practices for Linux guests": http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427 -- Pasi -- users mailing list users@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: [fedora-virt] Fedora 12 Xen guests (domU) and hosts (dom0)
On Fri, Jan 15, 2010 at 01:54:09PM +0200, Pasi Kärkkäinen wrote: > Hello, > > I thought of writing some information about running Fedora 12 Xen guests > and also Fedora 12 Xen hosts/dom0. > > Fedora 12 includes the upstream Linux pv_ops Xen domU support in the default > kernel. > By using virt-install or virt-manager you can install Fedora 12 Xen PV > (paravirtual) guests directly from network, for example on RHEL 5.4, > CentOS 5.4, or Fedora Xen dom0/host. > > If you want to run Fedora 12 Xen dom0 (host), there are some extra steps > needed. Fedora 12 ships with Xen hypervisor and management tools > (Xen 3.4.1, and Xen 3.4.2 in the F12 updates), but the required Xen dom0 > capable host kernel is not included in Fedora atm/yet. > > General information about Xen dom0 status in Fedora: > http://fedoraproject.org/wiki/Features/XenPvopsDom0 > > There are a couple of different ways to get and install a Xen dom0 > capable kernel to Fedora 12 host: > > - By using pre-packaged pv_ops xendom0 kernel rpms by M A Young. his > repository: > http://fedorapeople.org/~myoung/dom0/ > > - Compiling and installing Xen dom0 capable kernel yourself/manually. > > There are many options to choose from, full list of the available Xen > dom0 capable kernels is here: > http://wiki.xensource.com/xenwiki/XenDom0Kernels > > The recommended dom0 kernel is the pv_ops kernel, which is in the > process of being cleaned up for upstream/mainline Linux inclusion. > > More information about pv_ops dom0 kernel, including the status > reports: > http://wiki.xensource.com/xenwiki/XenParavirtOps > > Xen developers are interested of both the success and failure reports > when using the Xen pv_ops dom0 kernel. > > > Tips for running Xen with Fedora 12: > > - Make sure you install all the latest Fedora 12 updates, since they > have an updated Xen version (3.4.2), and also fix a bug in > python-virtinst tool to make Xen guest console keymaps work properly: > https://bugzilla.redhat.com/show_bug.cgi?id=533707 > > - Recent versions of Xen pv_ops dom0 kernel renamed some xen > backend driver modules to have "xen-" prefix in them, for > example evtchn module became xen-evtchn. Fedora Xen 3.4.2 init > scripts take care of this, and load the correct modules, but > Xen 3.4.1 doesn't do this automatically, causing xend fail to > start in dom0/host before the modules are loaded manually. > > - There are some upcoming apic-related changes coming in pv_ops > dom0 kernel, which will require a patch to Xen hypervisor. > This patch is not yet included in the Fedora Xen rpms. > The patch will be added to Fedora Xen rpms when the upstream > pv_ops kernel starts to require/use it. > > - pv_ops dom0 kernel currently lacks blktap2 support, so using > tap:aio: backend disk image files is not yet possible. > Xen file: backend image files work though. > > At the moment it's recommended to use LVM volumes for guest > disks (Xen phy: backend). > > - virt-manager seems to work OK on Fedora 12 Xen dom0. > > - If you experience problems related to Fedora 12 guests (domU) > kernel crashing (especially related to save/restore/migration), > install the latest Fedora updates to the guest. There has been > a lot of Xen guest related fixes in the upstream Linux recently. > These fixes will appear in Fedora when the kernel gets updated > to include the latest stable upstream fixes. > Replying to myself again.. I forgot one thing from the list of tips: - Disable selinux from /etc/selinux/config to make it easier to use custom directories for storing Xen guest image files and prevent other problems from happening. -- Pasi -- users mailing list users@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
