Boston Linux Installfest XXVII Saturday November 10, 2007 Reminder today
Boston Linux Installfest XXVII When: Saturday, November 10, 2007 from 9:00 am to 5:00 pm Where: MIT Building E-51, Room 061 Parking: parking is available in front of the building with a ramp. Please refer to the BLU website (http://www.blu.org) for further information and directions. Parking is available in front of the building on Amherst St. Enter the building, and take the elevator to your left down 1 floor. Room 061 is opposite the elevator. -- Jerry Feldman [EMAIL PROTECTED] Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 signature.asc Description: PGP signature ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Power to the Pedants
On Nov 9, 2007 11:29 PM, Paul Lussier [EMAIL PROTECTED] wrote: Why on Earth did you take *that* remark seriously? ;-) IOW, I was trolling for more pedantry :) Oh, well. That's different. Carry on, then. ;-) -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Fedora Eight is out on the streets!
On Nov 9, 2007 3:47 PM, mike shlitz [EMAIL PROTECTED] wrote: ... I'm pretty much stuck with Comcast for TV and Internet. I've had nothing but issues with their internet service ... My experience has been that consumer Internet performance varies tremendously by locale. So one guy can love his Comcast, another guy in the next down over has nothing but problems. :-( Several family members using the internet simultaneously, results in a slowdown ... You may want to look into traffic control (priority queuing, bandwidth reservation, rate limiting) on your router. The interactions between multiple protocol streams can be complex, especially on an asymmetric feed. The classic example is BitTorrent on an asymetric feed. The feed can suck down a lot, but can only send out a little; meanwhile, the rest of the swarm is trying to suck a lot from you. If you don't properly cap the outgoing rate, you'll cause congestion, which impacts everything. For example, if I don't cap BitTorrent's outgoing rate, I top out at around 150 Kbyte/sec incoming, and my connection is very slow for web browsing. If I cap outgoing at 36 Kbyte/sec, I get up to 600 Kbyte/sec incoming, and the web is still pretty responsive. In other words, telling it to go slower made things go faster. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Power to the Pedants
IOW, I was trolling for more pedantry :) Oh, well. That's different. Carry on, then. ;-) My wife custom-ordered a button for me I'm not Pompous, I'm Pedantic There's a difference -- Bill [EMAIL PROTECTED] [EMAIL PROTECTED] ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Ignition (was Re: tftp config problem (ltsp))
[EMAIL PROTECTED] wrote: Date: Fri, 09 Nov 2007 16:07:18 + From: sean [EMAIL PROTECTED] During the boot process was getting error notices about not being able to connect to the nfs server. Did some research and found this sometimes occurs when the speed of the server nic is so much faster then the client nic. Apparently this showed up with the 2.6 kernel. Care to share what the problem/solution was? This sounds like something which others on this list might likely encounter. Could not find where I saw the original write up. But it has to do with the NIC in the server box being 1G and the NIC in the test laptop being only 100MB. Something about such a wide spread in the speed capabilities causes the slower NIC not to be able to keep up with the faster one. In the prelinux.cfg directory I added the last line to the default file. prompt 0 label linux kernel bzImage-2.6.17.8-ltsp-1 append rw root=/dev/ram0 initrd=initramfs.gz MOPTS=nolock,ro,wsize=2048,rsize=2048 ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Ignition (was Re: tftp config problem (ltsp))
Did some research and found this sometimes occurs when the speed of the server nic is so much faster then the client nic. Apparently this showed up with the 2.6 kernel. [...] Could not find where I saw the original write up. But it has to do with the NIC in the server box being 1G and the NIC in the test laptop being only 100MB. I suspect that such mismatches are not the problem, because the fact that *any* bits are flowing means that a whole bunch of low-level plumbing is working properly. In particular, it means that the system(s) in question have autonegotiated (or maybe been hard configured to operate at) compatible transmission rates / duplexes at the PHY level. Once that's all rigged up I think you're unlikely to see errors due to overruns because the protocols in question (DHCP, TFTP, etc) are designed to prevent that, so it's rare except when one or more parties to the conversation have b0rken implementations... ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Ignition (was Re: tftp config problem (ltsp))
As a programmer, I find your faith in computers amusing. Considering that computers have the ability to transition into an infinitude of wrong states (eg. Texas) I daily give praise and thanks that His Noodly Appendages somehow keep most systems operating more or less within spec. But that's a separate discussion... I'm just talking about probabilities; all I said was that problems like bitrate mismatches at the PHY level or receiver overruns due to protocol errors are unlikely to be the culprit. Yes, such errors are possible, but it's much more likely that some basic configuration botch is to blame, so that's where I'd start my debugging if it were my system(s). ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Ignition (was Re: tftp config problem (ltsp))
On Nov 10, 2007 4:05 PM, Michael ODonnell [EMAIL PROTECTED] wrote: ... you're unlikely to see errors due to overruns because the protocols in question (DHCP, TFTP, etc) are designed to prevent that ... As a programmer, I find your faith in computers amusing. (Well, I'm more of a sysadmin than a programmer, but I've done my share.) -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Fedora Eight is out on the streets!
Date: Sat, 10 Nov 2007 13:27:52 -0500 From: Ben Scott [EMAIL PROTECTED] The classic example is BitTorrent on an asymetric feed. The feed can suck down a lot, but can only send out a little; meanwhile, the rest of the swarm is trying to suck a lot from you. If you don't properly cap the outgoing rate, you'll cause congestion, which impacts everything. For example, if I don't cap BitTorrent's outgoing rate, I The situation is even more bleak with technologies like RADSL. The RA in RADSL stands for Rate-Adaptive. The difference between RADSL and ADSL (Asymmetric DSL) is that, with RADSL, the bandwidth allocated to the upstream and downstream channels is changed according to which channel is used more. As downstream traffic increases (say, because you're downloading something like, oh, Fedora 8), bandwidth is reallocated to the downstream channel and taken away from the upstream channel. This is in contrast to ADSL, in which there are fixed-size channels for each of up/downstream communication. Now, the RADSL scheme would be fine, if it weren't for one very important (and very very BAD!) fact: With RADSL, the amount of downstream bandwidth lost is about 10 times the amount of upstream bandwidth gained. So, if you start uploading another 1KB/s, you lose about 10KB/s from your download bandwidth! So, if you have a 1Mbps/128kbps RADSL, you'll either get the full 1Mbps down and 0bps up, the full 128kbps up and 0bps down, or a 10:1 weighted combination of the two. So, if you're downloading at 512kbps and uploading at 64kbps, you've actually SATURATED you're supposedly 1Mbps/128kbps link. In this case, you're really only getting HALF the stated speeds. The situation is even worse if you want to try and have equal up/down stream rates. Doing the math: 10*D+U=1Mbps, with U=D, you get: U = D = 91kbps. That is to say: if you have a 1Mbps/128kbps RADSL link *and* are uploading at the same rate that you are downloading, your bandwidth will top-out at a mere 91kbps on each channel. In this case, you're getting a total bandwidth of 182kbps, or just 18% of the link's stated speed. Unfortunately, many companies that sell so-called ADSL are actually selling you RADSL. Verizon is one of them. They'll tell you that you're getting (to continue the above example) a 1Mbps/128kbps ADSL service. But, when you plug in your equipment and test it, you'll more likely than not discover that they've actually given you RADSL. The salespeople don't know the difference. They don't know what the R means (let alone how important the distinction is), so they just leave it out and call their product ADSL. When I shop for DSL, I make sure to *explicitly ask* if what they're offering me is ADSL or RADSL. And if they've never heard of RADSL, I ask to talk to someone who has. Because if you don't ask, you may only be getting 20%-50% of what you think you're paying for. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Comcast!?!?
The problem is that they are local. It's still not available in this part of Goffstown, but cable is so I'm stuck with Comcast. I guess that's not entirely true. I could go back to dial up. Mike Miller - Original Message - From: TARogue [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 09, 2007 12:24 PM Subject: Re: Comcast!?!? On Fri, 9 Nov 2007, Tony Lambiris wrote: Can anyone recommend a good broadband provider in the Manchester area? Im with Comcast right now, refuse to go to Verizon due to their company practices, curious if anyone out there is using something else? MV Communications offers DSL for rates from $25 to $75 for residential usage ($25 to $85 for commercial). They're a great local resource. Tom -- TARogue (Linux user number 234357) On a scale from 1 to 10, people are stupid -- Tengis (from Hardforum.com) ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/ ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Comcast!?!?
From: mike miller [EMAIL PROTECTED] Date: Sat, 10 Nov 2007 18:20:48 -0500 The problem is that they are local. It's still not available in this part of Goffstown, but cable is so I'm stuck with Comcast. I guess that's not entirely true. I could go back to dial up. What is meant by local, when you're dealing with something the size of the Internet, varies according to who you talk to (and what their subnet is, ha ha). MV is based in Manchester, but I personally wouldn't call that local. Still, it's still more local than Boston or New York. Have you called them and asked if they serve Goffstown? As they say, you never know until you know. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Ignition (was Re: tftp config problem (ltsp))
On Nov 10, 2007 5:05 PM, Michael ODonnell [EMAIL PROTECTED] wrote: all I said was that problems like bitrate mismatches at the PHY level or receiver overruns due to protocol errors are unlikely to be the culprit. They may be unlikely, but they sure do happen a lot. When these problems happen, the cards usually talk just fine, and you can usually ping and do other simple diagnostics, but put a heavy traffic load on and everything goes to hell. I suspect it's that one end can send so much faster than the other that buffers fill up and frames start getting dropped by the switch. The Ethernet stuff is all Working As Designed, but that doesn't mean your computers will successfully transfer data. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
A plague of daemons and the Unix Philosophy
Okay, so I installed Fedora 8 today. As is my custom, I turned off the various and sundry magic daemons that Fedora's been shipping for years and years. These are daemons which do various magic things, like detect my hardware, mount my disks, and so on. I've never liked those things. They're over-complicated. They suffer from high coupling and low cohesion. They re-invent wheels that have existed for years or decades, to no apparent gain. They're poorly documented. They do not grok The Unix Philosophy. Plus, I've always been able to do a better job at knowing my hardware and mounting my disks than the machine can. This is largely because I know what I plan on doing, and the machine doesn't. Same reason I prefer a standard transmission to an automatic. An automatic transmission doesn't know which way I'm going to turn. In Fedora 8, a daemon has shown up called ConsoleKit. The job of this daemon is apparently to track login sessions. Why on God's green Earth do we need a daemon -- an always running background process -- for this? It could just as easily be done using library routines that get invoked only when needed (i.e., login, logout, user switch, etc.). I keep expecting these design failures to improve, as people realize the error of their ways. However, at least in Fedora, the opposite has been happening: More and more of these things appear with each release. This wouldn't be so bad, except for the fact that in Fedora 8, it's apparently mandatory to run these daemons for things to work properly. Shut them down, and I get constantly spewing errors and no sound. The sound appears to be a permissions issue. Apparently ConsoleKit and/or haldaemon is responsible for granting my user account permissions to the sound device nodes under /dev/. Even worse, this functionality is apparently broken. If I login on the console, /dev/mixer gets an ACL entry granting my account permission. If I run startx, that ACL entry is removed. [ALT]+[F1] back to text console, it comes back. [ALT]+[F7] back to text console, it goes away. Um. Who thought that would be a good idea? Is this the way the architects intend things to be? Are the people behind Fedora/KDE/GNOME/FreeDesktop.org/whatever really intent on making Linux as complicated and inter-coupled as possible? Have they completely abandoned the Unix Philosophy? I'm asking here because I know there are people reading this list who are close to the source. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Ignition (was Re: tftp config problem (ltsp))
Did some research and found this sometimes occurs when the speed of the server nic is so much faster then the client nic. Apparently this showed up with the 2.6 kernel. [...] Could not find where I saw the original write up. But it has to do with the NIC in the server box being 1G and the NIC in the test laptop being only 100MB. I suspect that such mismatches are not the problem, because the fact that *any* bits are flowing means that a whole bunch of low-level plumbing is working properly. Not at all! In my NFS on Tru64 Unix days, I was horrified at some of the abysmal buffering on some top of the line Gigabit Ethernet switches. A typical box could buffer 350 KB, i.e. 2.8 Mb, and that is about 3 msec of GbE wire time. Silly me figured a switch could buffer at least a second's worth of data before discarding data, maybe 100 msec at worst. I would love to get my paws on the marketroid that suggested people should sell Gbe for a corporate backbone and servers with 100 Mb to the workstations. In my case, we typically had 8 48 KB NFS data messages in flight (UDP) or 8 64 KB when using NFS over TCP. 384-512 KB. Oops. (And I used 1 MB TCP window sizes in part to get around an interesting problem with BSD's TCP code sharing a socket across multiple threads and in part to get the bandwidth x delay product to get full GbE on a network with a delay as long as 8 msec. I couldn't bring myself to make it bigger.) Given the cost of memory these days, I figured something else must have been behind the atrocious buffering than RAM, and found a big clue in a Cisco document that talked about the FIFOs connecting sections in a GbE switch. Those are basically large, byte at a time shift registers and far more expensive that DRAM. On the smallish switches I had, I couldn't find statistics in the boxes for the number of messages discarded due to congestion. I suspect that may be a marketing solution to what would have been an obvious customer support issue. I never tried buying/borrowing consumer grade switches to abuse, but I'm sure I'd be appalled. Last I looked, implementations of TFTP never let much data on the wire, so that may not be the problem. However, I can imagine a zillion ways something else could screwup. At any rate, without good network traces (at both the 1 GbE and 100 MbE sides), all we can do is speculate where things might be failing. Using a homogenous speed on a network doesn't work well either at times. One NFS client reading from two servers can clog its incoming link just fine. -Ric Werme ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Ignition (was Re: tftp config problem (ltsp))
On Nov 10, 2007 11:14 PM, Ric Werme [EMAIL PROTECTED] wrote: I would love to get my paws on the marketroid that suggested people should sell Gbe for a corporate backbone and servers with 100 Mb to the workstations. It makes sense at first glance. Multiple clients, one server, 10 clients can pull their full feed from the server. But you need some kind of flow control to make such a scenario work well, and Ethernet flow control is an inconsistent mess. Last I looked, implementations of TFTP never let much data on the wire, so that may not be the problem. I was confused about that at first, too. But I went back and re-read the OP more carefully, and noticed that the speed mismatch issues he encountered were after he got the thing to boot, and had moved on to having trouble with (wait for it) NFS! -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Ignition (was Re: tftp config problem (ltsp))
It makes sense at first glance. Multiple clients, one server, 10 clients can pull their full feed from the server. But you need some kind of flow control to make such a scenario work well, and Ethernet flow control is an inconsistent mess. It's more that you need to make sure that everyone (client, server, switches) uses consistent flow control. Every switch I participated in engineering had to support a freaking million types of flow control, and then no one ever bothered to use it because setting it up end-to-end was too hard. --DT you asked for it, now USE it VZ ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
