- WLUG - wlug.mailman3.com

Fwd: Urgent Need for Software QA Instructor in Boston, MA

by albutler33＠netscape.net

Hello all, Here's an opportunity I thought I'd pass along. Al Butler member of WLUG (haven't attended for quite a while) -----Original Message----- From: april01(a)o-s-tech.com To: albutler33(a)netscape.net Sent: Thu, 17 May 2007 8:59 PM Subject: Urgent Need for Software QA Instructor in Boston, MA Dear Aljerin, Open Systems Technology Services has an urgent need for an experienced Software Quality Assurance Instructor. Topics Software development life cycle-the product view Software configuration management (SCM) Software quality assurance Testing, validating and evaluating Special topics Planning, organizing, implementing and managing for SQA ------------------- Location: Boston, MA Date: June 11-13 Rate: $300 day/ 1099 Please let me know ASAP if you are available or know of someone who have experience teaching Linux. Classes will begin at 8am each day. Introduction to Linux, 3 days March 19th - 21st Linux Admin I, 5 days March 26th - 30th Linux Admin II, 5 days April 9th - 13t Rate: $500.00/day Job Description: . If you are available, email your resume (in word format) and availability with a contact number by 5:00pm, Monday, May 21, 2007. Thank you, April Washington Open Systems Technology Services, Inc. Email: April01(a)o-s-tech.com ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection.

May 20, 2007

ALSA hanging (Gentoo AMD64)

by Eric Stein

Hi all, I have a very strange problem. Last night I updated all my packages and rebooted. On boot, alsasound started (boot runlevel), but while trying to restore mixer levels, it hung. I had to boot to a livecd and remove alsasound from boot to even start my system. I tried removing the old state file (in case the format changed and it was breaking because of that), but it wouldn't start without it. glamdring ~ # /etc/init.d/alsasound start * One of the files in /etc/{conf.d,init.d} or /etc/rc.conf * has a modification time in the future! * Loading ALSA modules ... [ ok ] * Restoring Mixer Levels ... * No mixer config in /var/lib/alsa/asound.state, you have to unmute your card! [ ok ] glamdring ~ # cd /var/lib/alsa/ glamdring alsa # l total 9 drwxr-xr-x 3 root root 152 May 17 16:26 ./ drwxr-xr-x 23 root root 568 May 17 03:17 ../ -rw-r--r-- 1 root root 0 May 17 16:26 .keep_media-sound_alsa-utils-0.9 -rw-r--r-- 1 root root 8073 May 17 12:50 asound.state.old drwxr-xr-x 2 root root 144 May 17 12:50 oss/ glamdring alsa # mv asound.state.old asound.state glamdring alsa # cd glamdring ~ # /etc/init.d/alsasound zap * Manually resetting alsasound to stopped state. glamdring ~ # /etc/init.d/alsasound start * Loading ALSA modules ... [ ok ] * Restoring Mixer Levels ... Which is where it hangs. Other alsa programs like alsaconf and alsamixer hang on startup, along with programs that attempt to use ALSA to output sound. I've tried reinstalling ALSA, I've tried revdep-rebuild, I've done modules-rebuild, and I'm at my wit's end. None of it seems to make sense, and Gnome isn't very happy about not having a sound output, so half of my GUI is missing. If anyone has some idea why this could be happening to me, please let me know. Eric

May 18, 2007

OT: HP9k E-class

by Desdinova

A bit OT, if you can reply off-list, that's fine. I just figure there's probably guys who know about crappy old minis here. I've got an E25 and I'm planning to replace the internal scsi drive, it shouldn't be any big deal, but this *is* HP. Are there any gotchas on drive geometry or size that I should watch for? Take care, des

May 17, 2007

Re: [Wlug] Follow-Up to Key Signing Party

by Jamie Guinan

On Thu, 17 May 2007, Eric Martin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Thanks to everyone who showed up to tonight's key signing party. Now > that we verified everybody had the correct key info and identification, > we actually have to sign each other's keys. We are using the keyserver > pgp.mit.edu. If that isn't your default, you can set it either in > ~/.gnupg/gpg.conf or at the command line for each command by using the > argument > - --keyserver pgp.mit.edu Is the "hkp://" prefix needed in gpg.conf? keyserver hkp://pgp.mit.edu > Below is an excerpt from the gpg Key Signing Party HowTo that explains > things in detail.(http://www.rubin.ch/pgp/kspa/gpg-party.en.html#ss3.8): > > 3.8 How to sign others' keys > > Step 1: Get a copy of the key > > Normally, you'll be working from a keyserver. However if you are signing > the key that is not available on a keyserver, you can use simply import > the key with gpg --import. If you are working with a keyserver, the > following command will download the key from the keyserver into your > public keyring. > > bash$ gpg --keyserver <keyserver> --recv-keys <Key_ID> > > If you get a read error, it means the keyserver is overloaded. Please, > try again in a few seconds. That worked Ok. > > Step 2: Fingerprint and Verify the key > > bash$ gpg --fingerprint <Key_ID> That too. > GPG will print out the fingerprint of the Key with <Key_ID > (the key > you just downloaded). Check the fingerprint against the checklist that > you where given at the party. Note: Don't check the fingerprint on your > checklist against the fingerprint on the web page as the server may not > send you the same key it displays on the web page. > > Step 3: Sign the key > > bash$ gpg --sign-key <Key_ID> Ok. > > If you have multiple private keys, you can specify which of your private > keys to sign the other persons public key with like this: > > bash$ gpg --default-key <Key_to_use> --sign-key <Key_ID> > > Step 4: Return or Upload the signed key > > If you are working with an entity which does not want their key on a > public keyserver, you should at this point you should return their > signed key back to them by their method of choice - normally encrypted > email. You should not send a public key to a keyserver with out the > permission of the key's owner. Publicizing a public key slightly reduces > the security of a key pair, therefor it is considered rude to make a key > more public than its owner desires. > > Most likely you are working with a keyserver. If that is the case, you > can send the signed key back to the keyserver like this: > > bash$ gpg --keyserver <keyserver> --send-key <Key_ID> > > You should see a success message like this: > > gpg: success sending to `<keyserver>' (status=200) > Congratulations, the signature of the other entity's key is now complete > and your signature has been incorporated into their public key. A trust > path has been established. This looked different for me, $ gpg --send-key A9413B9F gpg: sending key A9413B9F to hkp server pgp.mit.edu $ No affirmative response, it just returned to the prompt. But the exit code was 0. $ echo $? 0 -Jamie [ not yet using gpg for mail ]

May 17, 2007

Follow-Up to Key Signing Party

by Eric Martin

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks to everyone who showed up to tonight's key signing party. Now that we verified everybody had the correct key info and identification, we actually have to sign each other's keys. We are using the keyserver pgp.mit.edu. If that isn't your default, you can set it either in ~/.gnupg/gpg.conf or at the command line for each command by using the argument - --keyserver pgp.mit.edu Below is an excerpt from the gpg Key Signing Party HowTo that explains things in detail.(http://www.rubin.ch/pgp/kspa/gpg-party.en.html#ss3.8): 3.8 How to sign others' keys Step 1: Get a copy of the key Normally, you'll be working from a keyserver. However if you are signing the key that is not available on a keyserver, you can use simply import the key with gpg --import. If you are working with a keyserver, the following command will download the key from the keyserver into your public keyring. bash$ gpg --keyserver <keyserver> --recv-keys <Key_ID> If you get a read error, it means the keyserver is overloaded. Please, try again in a few seconds. Step 2: Fingerprint and Verify the key bash$ gpg --fingerprint <Key_ID> GPG will print out the fingerprint of the Key with <Key_ID > (the key you just downloaded). Check the fingerprint against the checklist that you where given at the party. Note: Don't check the fingerprint on your checklist against the fingerprint on the web page as the server may not send you the same key it displays on the web page. Step 3: Sign the key bash$ gpg --sign-key <Key_ID> If you have multiple private keys, you can specify which of your private keys to sign the other persons public key with like this: bash$ gpg --default-key <Key_to_use> --sign-key <Key_ID> Step 4: Return or Upload the signed key If you are working with an entity which does not want their key on a public keyserver, you should at this point you should return their signed key back to them by their method of choice - normally encrypted email. You should not send a public key to a keyserver with out the permission of the key's owner. Publicizing a public key slightly reduces the security of a key pair, therefor it is considered rude to make a key more public than its owner desires. Most likely you are working with a keyserver. If that is the case, you can send the signed key back to the keyserver like this: bash$ gpg --keyserver <keyserver> --send-key <Key_ID> You should see a success message like this: gpg: success sending to `<keyserver>' (status=200) Congratulations, the signature of the other entity's key is now complete and your signature has been incorporated into their public key. A trust path has been established. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGS+VsaiVxdKlBO58RAs3xAJ0W7SyjfbQtwHwDaHeWG5EgeWWXzgCfQ8pT W40gnhPVnkQ3u7E1jbXALvU= =GM/c -----END PGP SIGNATURE-----

May 17, 2007

Re: [Wlug] PGP Key Signing Party

by Gregory Avedissian

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here's my fingerprint: pub 1024D/5DC682A4 2004-04-17 [expires: 2009-04-16] Key fingerprint = 4DF6 E8E1 5521 6ECC 7A3E E7F0 BF02 ADEA 5DC6 82A4 Greg Avedissian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGS8i0vwKt6l3GgqQRAui5AJ4my59DCPMhLXnwIsZSLvvL3Qh62ACeMLt1 hJHV/oml3PBTo5117s9YXOA= =NO0Y -----END PGP SIGNATURE-----

May 17, 2007

Last-Minute Emergency, Unable to Attend

by Terry S

Hello, I had a phone call at 6:07 that required me to go out for a while, and did not have time to email. (I'm the one with the camera.) Hopefully, someone else just "happened" to have one, but I can take pictures at our next meeting if needed. How did the key-signing go? Terry

May 17, 2007

Re: [Wlug] large file performance on linux

by Jeff Moyer

==> On Wed, 16 May 2007 22:19:14 +0000, brad noyes <maitre(a)ccs.neu.edu> said: brad> All, brad> here's a summary of what i have tried so far. I have tried using the O_DIRECT brad> and O_SYNC flags with open(2) and i have been using a non-journalling brad> filesystem, ext2. None of these options have yielded any better performance at brad> the rates i'm looking for. brad> I have not tried AIO. AIO will allow you to drive your disk subsystem better than synchronous writes; I really think this would solve your problem. For an example of an AIO app, you can google for aio-stress.c. Or, send me some code and I'll help get you started. -Jeff

May 16, 2007

Re: [Wlug] large file performance on linux

by brad noyes

All, here's a summary of what i have tried so far. I have tried using the O_DIRECT and O_SYNC flags with open(2) and i have been using a non-journalling filesystem, ext2. None of these options have yielded any better performance at the rates i'm looking for. I have not tried AIO. I don't think i can use a non 32-bit kernel on the xeons. Correct me if i'm wrong (it's happened before). As a temporary solution i created a memory filesystem, by $> mount -t tmpfs tmpfs -o size=6G /data/memory The writes are fast however i need another process to progressively move data out of the memory filesystem since i don't have enough memory to hold all 22GB of data i need. For those interested i have attached a small program which will use different options to open and profile the fwrite calls. To compile simply do $> sh ./testwrite.c $> ./testwrite -h $> ./testwrite -l 16 file.out I just wanted to keep you all updated. Thanks for all your help. I'll keep trying various ideas. I wish i could make it to the meeting to buy you all pizza for your help. Perhaps next month. Thanks, -- Brad

May 16, 2007

Re: [Wlug] Meeting tomight

by Brains

freak4uxxx(a)gmail.com wrote: > I might be slightly delayed tonight, small family thing that needs to be taken care of. I shouldn't be late but I just wanted to let people know. > > -Eric I suspect a lot of people are going to be running a little late this evening, including me... Frank "Rain, sleet, or snow, the LUGman marches on..."

May 16, 2007

Meeting tomight

by freak4uxxx＠gmail.com

I might be slightly delayed tonight, small family thing that needs to be taken care of. I shouldn't be late but I just wanted to let people know. -Eric

May 16, 2007

Re: [Wlug] PGP Key Signing Party

by Mike

Sorry guys. I don't think I am going to be showing up to do the inclement weather. If you see anyone posing as me, well, then it is not me. I can always trade keys w/ peeps next time. Cheers, Mike <quote who="Andy Stewart"> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Eric Martin wrote: >> Just a reminder that we are having a PGP Key Signing Party tomorrow for >> WLUG. If you're name isn't listed below, I do not have your info (and >> you should get it to me if you want to be on the list). I know Andy >> said noon tomorrow but I'll take stuff until 4pm. Don't forget your two >> forms of ID and I'll see you tomorrow. >> >> Eric Martin >> Gregory M. Avedissian >> Walt Sawyer >> Alexander Pennace >> Doug Mildram >> Keith Wright >> Alex Weiss >> Andrew M. Stewart >> James Philip Gray >> >> -Eric > > HI Eric, > > Thanks for sending out the meeting reminder! > > I'll see you all on Wednesday evening with my shiny new passport. :-) > > Later, > > Andy > > > - -- > Andy Stewart, Founder > Worcester Linux Users' Group (http://www.wlug.org) > Chelmsford Linux Meetup Group (http://linux.meetup.com/393) > Amateur Radio: KB1OIQ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2 (GNU/Linux) > Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org > > iD8DBQFGSkvGHl0iXDssISsRApWmAJ9HpIERvKHryJXnIeBo8ZfoJnqBygCeIF2I > tQxc9xAb6JDHR8dbSTc3yNA= > =v7Xx > -----END PGP SIGNATURE----- > _______________________________________________ > Wlug mailing list > Wlug(a)mail.wlug.org > http://mail.wlug.org/mailman/listinfo/wlug > -- They who would give up an essential liberty for temporary security, deserve neither liberty or security --Ben Franklin

May 16, 2007

Re: [Wlug] large file performance on linux

by Andre Lehovich

--- brad noyes <maitre(a)ccs.neu.edu> wrote: > Do you have any suggestions on how to speed up performance > on these writes, filesystem options, kernel options, other strategies, etc? How are you doing the writes, using fwrite(3), write(2), or mmap(2)? I've seen dramatic speedups reading large files using memory-mapped I/O. > - I have also tried spooling over several files (a la multiple volumes) > but i see no difference in performance. In fact, i think this actually > hinders performance a bit. Do you mean multiple physical spindles or drives here? (I'd expect a slow down using multiple partitions on the same physical drive.) > - I keep my own giant memory buffer where all the data is stored and > then it is written to disk in a background thread. This helps, but > i run out of space in the buffer before i finish taking data. With memory-mapped I/O you could just maintain the buffer and have the kernel page it out to disk for you as needed; no need to shuffle stuff around with a background thread. --Andre ____________________________________________________________________________________Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting

May 16, 2007

Re: [Wlug] large file performance on linux

by Jeff Moyer

==> On Wed, 16 May 2007 19:19:45 +0000, brad noyes <maitre(a)ccs.neu.edu> said: brad> On Wed, May 16, 2007 at 02:40:38PM -0400, Jeff Moyer wrote: brad> > ==> On Wed, 16 May 2007 12:59:54 -0400, Jeff Moyer <jmoyer(a)redhat.com> said: brad> > brad> > Jeff> Look under /proc/sys/vm. Documentation for these variables might be brad> > Jeff> in Documentation/filesystems/proc.txt (it's not always up-to-date). brad> > Jeff> But, as I said, I don't think this is the right avenue to explore. brad> > Jeff> You can get more predictable results by using AIO+O_DIRECT (or maybe brad> > Jeff> even O_SYNC as another mentioned). brad> > brad> > One other thing worth mentioning is that you should be doing I/O in brad> > large block sizes. What size are you currently using for your write brad> > buffers? brad> > brad> i'm writing in 16777216 byte chunks. That happens to be evenly divisible by 512 brad> for the O_DIRECT flag. However every time i try to use that flag the file gets brad> created, but nothing gets written. I've been looking online for an example. Are you aligning your buffers on a 512 byte boundary? Man posix_memalign. brad> I don't know if this means anything, but i ran brad> hdparm -T /dev/sdb1 brad> Timing cached reads: 1369MB in 2.00 seconds == 698.14MB/sec brad> hdparm -T --direct /dev/sdb1 brad> Timing O_DIRECT cached reads: 136 in 2.00 seconds == 66.54MB/sec brad> It really seems that 53MB/s shouldn't be hard. I have fairly heavy hardware, brad> scsi320 in a raid1 configuration. So long as nothing else is going on at the time. =) -Jeff

May 16, 2007

Re: [Wlug] large file performance on linux

by Karl Hiramoto

brad noyes wrote: > On Wed, May 16, 2007 at 02:40:38PM -0400, Jeff Moyer wrote: > >> ==> On Wed, 16 May 2007 12:59:54 -0400, Jeff Moyer <jmoyer(a)redhat.com> said: >> >> Jeff> Look under /proc/sys/vm. Documentation for these variables might be >> Jeff> in Documentation/filesystems/proc.txt (it's not always up-to-date). >> Jeff> But, as I said, I don't think this is the right avenue to explore. >> Jeff> You can get more predictable results by using AIO+O_DIRECT (or maybe >> Jeff> even O_SYNC as another mentioned). >> >> One other thing worth mentioning is that you should be doing I/O in >> large block sizes. What size are you currently using for your write >> buffers? >> >> > i'm writing in 16777216 byte chunks. That happens to be evenly divisible by 512 > for the O_DIRECT flag. However every time i try to use that flag the file gets > created, but nothing gets written. I've been looking online for an example. > > I don't know if this means anything, but i ran > hdparm -T /dev/sdb1 > Timing cached reads: 1369MB in 2.00 seconds == 698.14MB/sec > hdparm -T --direct /dev/sdb1 > Timing O_DIRECT cached reads: 136 in 2.00 seconds == 66.54MB/sec > > > It really seems that 53MB/s shouldn't be hard. I have fairly heavy hardware, > scsi320 in a raid1 configuration. > > -- Brad > _______________________________________________ > That is CACHED read.. your uncached write will be slower.. run a bonnie++ benchmark on your disks. You might want to switch to raid 0 or raid 1+0. And use a 64 bit kernel to be able to allocate more than 3G of ram. -- -- Karl Hiramoto http://karl.hiramoto.org/ US VOIP: (1) 603.966.4448 Spain Casa (34) 951.273.347 Spain Mobil (34) 617.463.826 Yahoo_IM = karl_hiramoto GTalk= karl.hiramoto [at] gmail [d0t] com -- Everyone complains of his memory, no one of his judgement.

May 16, 2007

Re: [Wlug] large file performance on linux

by brad noyes

On Wed, May 16, 2007 at 03:19:17PM -0400, John Stoffel wrote: > >>>>> "brad" == brad noyes <maitre(a)ccs.neu.edu> writes: > > brad> I am seeing some really slow performance regarding large files > brad> on linux. I write a lot of data points from a light sensor. The > brad> stream is about 53 Mb/s and i need to keep this rate for 7 > brad> minutes, that's a total of about 22Gb. I can sustain 53Mb/s > brad> pretty well until the file grows to over 1Gb or so, then things > brad> hit the wall and the writes to the filesystem can't keep up. The > brad> writes go from 20ms in duration to 500ms. I assume the > brad> filesystem/operating system is caching writes. Do you have any > brad> suggestions on how to speed up performance on these writes, > brad> filesystem options, kernel options, other strategies, etc? > > You've already had a good bunch of suggestions, but I've got some > questions on your hardware. > i don't mind answering more questions :). > - cpu? dual xeons (not sure if they are hyper threaded or dual core) cpu MHz: 3067.044 cache size: 512 KB > - memory - 12gb I know > - disk(s) SCSI hard drives, i believe they are SCSI 320. I have tried in a raid1 as well as stand alone. > - RAID setup at all? tried using RAID1. I'm afraid to try RAID0 b/c the data is pretty vital, but i may try it. > > One way to get more performance would be to add another disk or two > and to stripe your data between them. This assumes you have enough > PCI bus bandwidth available as well. You don't say how you're > capturing the light sensor data, but it's obviosly not over a serial > port or some other slow device. Network? So if you've got 53 > Mbyte/second comming into the system, and another 53Mbytes/second > writing out to disk, then you're starting to get close to the > 132Mbytes/sec bandwidth of the PCI bus. > Good point. Its not network, but it is still on the PCI bus. It doesn't seem that bandwidth is really a problem b/c it works great for the first minute. Once the file grows past 1GB the writes are extremely slow. Like i said above i might try the RAID0 configuration. > Finding a motherboard with two or more PCI busses would help. Or > something with PCI-E busses. It all depends on your budget and the > data acquisition tool you're using. > If i were to redesign this system i would really like to use PXI, which was really meant for this sort of thing. I'm really retrofitting my design to to something different than intended. Thanks -- Brad

May 16, 2007

Re: [Wlug] large file performance on linux

by brad noyes

On Wed, May 16, 2007 at 02:40:38PM -0400, Jeff Moyer wrote: > ==> On Wed, 16 May 2007 12:59:54 -0400, Jeff Moyer <jmoyer(a)redhat.com> said: > > Jeff> Look under /proc/sys/vm. Documentation for these variables might be > Jeff> in Documentation/filesystems/proc.txt (it's not always up-to-date). > Jeff> But, as I said, I don't think this is the right avenue to explore. > Jeff> You can get more predictable results by using AIO+O_DIRECT (or maybe > Jeff> even O_SYNC as another mentioned). > > One other thing worth mentioning is that you should be doing I/O in > large block sizes. What size are you currently using for your write > buffers? > i'm writing in 16777216 byte chunks. That happens to be evenly divisible by 512 for the O_DIRECT flag. However every time i try to use that flag the file gets created, but nothing gets written. I've been looking online for an example. I don't know if this means anything, but i ran hdparm -T /dev/sdb1 Timing cached reads: 1369MB in 2.00 seconds == 698.14MB/sec hdparm -T --direct /dev/sdb1 Timing O_DIRECT cached reads: 136 in 2.00 seconds == 66.54MB/sec It really seems that 53MB/s shouldn't be hard. I have fairly heavy hardware, scsi320 in a raid1 configuration. -- Brad

May 16, 2007

Re: [Wlug] large file performance on linux

by John Stoffel

>>>>> "brad" == brad noyes <maitre(a)ccs.neu.edu> writes: brad> I am seeing some really slow performance regarding large files brad> on linux. I write a lot of data points from a light sensor. The brad> stream is about 53 Mb/s and i need to keep this rate for 7 brad> minutes, that's a total of about 22Gb. I can sustain 53Mb/s brad> pretty well until the file grows to over 1Gb or so, then things brad> hit the wall and the writes to the filesystem can't keep up. The brad> writes go from 20ms in duration to 500ms. I assume the brad> filesystem/operating system is caching writes. Do you have any brad> suggestions on how to speed up performance on these writes, brad> filesystem options, kernel options, other strategies, etc? You've already had a good bunch of suggestions, but I've got some questions on your hardware. - cpu? - memory - 12gb I know - disk(s) - RAID setup at all? One way to get more performance would be to add another disk or two and to stripe your data between them. This assumes you have enough PCI bus bandwidth available as well. You don't say how you're capturing the light sensor data, but it's obviosly not over a serial port or some other slow device. Network? So if you've got 53 Mbyte/second comming into the system, and another 53Mbytes/second writing out to disk, then you're starting to get close to the 132Mbytes/sec bandwidth of the PCI bus. Finding a motherboard with two or more PCI busses would help. Or something with PCI-E busses. It all depends on your budget and the data acquisition tool you're using. John

May 16, 2007

Re: [Wlug] large file performance on linux

by Jeff Moyer

==> On Wed, 16 May 2007 12:59:54 -0400, Jeff Moyer <jmoyer(a)redhat.com> said: Jeff> Look under /proc/sys/vm. Documentation for these variables might be Jeff> in Documentation/filesystems/proc.txt (it's not always up-to-date). Jeff> But, as I said, I don't think this is the right avenue to explore. Jeff> You can get more predictable results by using AIO+O_DIRECT (or maybe Jeff> even O_SYNC as another mentioned). One other thing worth mentioning is that you should be doing I/O in large block sizes. What size are you currently using for your write buffers? -Jeff

May 16, 2007

Re: [Wlug] large file performance on linux

by Jeff Moyer

==> On Wed, 16 May 2007 16:26:53 +0000, brad noyes <maitre(a)ccs.neu.edu> said: brad> On Wed, May 16, 2007 at 11:38:09AM -0400, Jeff Moyer wrote: brad> > ==> On Wed, 16 May 2007 14:53:16 +0000, brad noyes <maitre(a)ccs.neu.edu> said: brad> > brad> > brad> Hello All, brad> > brad> I am seeing some really slow performance regarding large files on linux. I brad> > brad> write a lot of data points from a light sensor. The stream is about 53 Mb/s and brad> > brad> i need to keep this rate for 7 minutes, that's a total of about 22Gb. I brad> > brad> can sustain 53Mb/s pretty well until the file grows to over 1Gb or so, then brad> > brad> things hit the wall and the writes to the filesystem can't keep up. The writes brad> > brad> go from 20ms in duration to 500ms. I assume the filesystem/operating system brad> > brad> is caching writes. Do you have any suggestions on how to speed up performance brad> > brad> on these writes, filesystem options, kernel options, other strategies, etc? brad> > brad> > Of course. Your data set is larger than the page cache, so when you brad> > hit the low watermark, it starts write-back. You can deal with this a brad> > few different ways, and I'll throw out the easiest ways first: brad> > 1) Get more memory brad> > 2) Get a faster disk brad> > brad> Ha :). I have 12GB of memory. Which actually brings me to another question. brad> How do i alter the per-process memory limit? I can only allocate a memory brad> buffer that is 3GB. I'd like to make use of the other 8GB left in the machine. brad> If i can double my buffer size i think i could sustain the 53MB/s for 7 brad> minutes that i need. I'm guessing that you're using a 32 bit system, is that right? 32 bit systems have the 3/1 memory split, unless you're using Ingo's 4/4 split patch (which Ubuntu doesn't carry, I think). brad> i'm using the 2.6.20 kernel from the ubuntu source tree. I recompiled it to get brad> the large memory support, up to 64GB. OK, yes, 32 bit system. brad> I was looking for some tunable vm options in sysctl, but i didn't see much that brad> made sense to me. If nothing else helps perhaps i will ask about the vm brad> options. Look under /proc/sys/vm. Documentation for these variables might be in Documentation/filesystems/proc.txt (it's not always up-to-date). But, as I said, I don't think this is the right avenue to explore. You can get more predictable results by using AIO+O_DIRECT (or maybe even O_SYNC as another mentioned). -Jeff

May 16, 2007

Re: [Wlug] Reminder: Upcoming PGP Key Signing Party

by Minkov, Ross

Eric, It's past the cutoff time as defined by Andy now. Can you share with us how many key fingerprints you have received so far? Thanks, Ross -----Original Message----- From: wlug-bounces(a)mail.wlug.org [mailto:wlug-bounces@mail.wlug.org] On Behalf Of Andy Stewart Sent: Wednesday, May 09, 2007 20:35 To: Worcester Linux Users Group Subject: [Wlug] Reminder: Upcoming PGP Key Signing Party -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 HI Everybody, At our next WLUG meeting on Wednesday, May 16th, we will have a PGP Key Signing Party hosted by Chuck Anderson and Eric Martin. Eric has previously sent out instructions, so please be sure to follow them, and direct any questions to Eric or Chuck. I have posted those instructions on the WLUG home page (see description for May WLUG Meeting). I suggest a cutoff of noon on Wednesday, May 16th, for sending your information to Eric. This will give Eric time to collect the necessary information prior to the meeting. Dust off those passports - you'll need them! Later, Andy - -- Andy Stewart, Founder Worcester Linux Users' Group (http://www.wlug.org) Chelmsford Linux Meetup Group (http://linux.meetup.com/393) Amateur Radio: KB1OIQ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGQmjGHl0iXDssISsRAr1rAJ91nX/DNXHjRie+dDYyVjrq8ePq2wCeN8DC Q+SoklLvcW6MfOaCGuvwKwU= =kUPV -----END PGP SIGNATURE----- _______________________________________________ Wlug mailing list Wlug(a)mail.wlug.org http://mail.wlug.org/mailman/listinfo/wlug

May 16, 2007

Re: [Wlug] large file performance on linux

by brad noyes

On Wed, May 16, 2007 at 11:38:09AM -0400, Jeff Moyer wrote: > ==> On Wed, 16 May 2007 14:53:16 +0000, brad noyes <maitre(a)ccs.neu.edu> said: > > brad> Hello All, > brad> I am seeing some really slow performance regarding large files on linux. I > brad> write a lot of data points from a light sensor. The stream is about 53 Mb/s and > brad> i need to keep this rate for 7 minutes, that's a total of about 22Gb. I > brad> can sustain 53Mb/s pretty well until the file grows to over 1Gb or so, then > brad> things hit the wall and the writes to the filesystem can't keep up. The writes > brad> go from 20ms in duration to 500ms. I assume the filesystem/operating system > brad> is caching writes. Do you have any suggestions on how to speed up performance > brad> on these writes, filesystem options, kernel options, other strategies, etc? > > Of course. Your data set is larger than the page cache, so when you > hit the low watermark, it starts write-back. You can deal with this a > few different ways, and I'll throw out the easiest ways first: > 1) Get more memory > 2) Get a faster disk > Ha :). I have 12GB of memory. Which actually brings me to another question. How do i alter the per-process memory limit? I can only allocate a memory buffer that is 3GB. I'd like to make use of the other 8GB left in the machine. If i can double my buffer size i think i could sustain the 53MB/s for 7 minutes that i need. > If those are not options, then you can tweak your application by using > AIO and O_DIRECT. This will allow you to drive your disk queue depths > a bit further and avoid the page cache. Check the man pages for > io_setup, io_submit, and io_getevents to get started. > I'll check out these options and man pages. > brad> Things I have tried: > brad> - I have tried this on a ext3 file system as well as an xfs filesystem > brad> with the same result. > > You may not want to use a journalled file system. If you must, > though, with ext3 you could try running with the data=writeback > option. > yup. I'll check this option out. > brad> - I have also tried spooling over several files (a la multiple volumes) > brad> but i see no difference in performance. In fact, i think this actually > brad> hinders performance a bit. > > I'm not sure I fully understand what you mean. Are you saying you > write to separate physical volumes, > Not physical volumes, but different files. By the end of the data acquisition i will end up with the files: data.01, data.02, data.03 ... etc. Each file is a 1GB in size or whatever i set the limit to be. The reason i did this is because i thought that as the file grows larger there are several layers of indirection in the inode to get to the actual data blocks on disk; and perhaps that might hinder performance. > and that you don't see any performance increase from doing so? > Correct. I don't see any improvement. At least no measurable performance improvement in the kind of rates i'm dealing with. > brad> - I keep my own giant memory buffer where all the data is stored and > brad> then it is written to disk in a background thread. This helps, but > brad> i run out of space in the buffer before i finish taking data. > > Right, this is exactly what happens in the OS. ;) Speaking of which, > you don't mention which kernel you are using. Could you please > provide that information? There are a few vm tunables that you could > try tweaking, but I really don't think they will help if your data set > is larger than memory. We can explore that option, though, if you > like. > i'm using the 2.6.20 kernel from the ubuntu source tree. I recompiled it to get the large memory support, up to 64GB. I was looking for some tunable vm options in sysctl, but i didn't see much that made sense to me. If nothing else helps perhaps i will ask about the vm options. > > p.s. In your head, is Mb Megabit or Megabyte? > the latter. Jamie already pointed this typo out to me :). Perhaps this time around my unit abbreviations are correct. Thanks for your input. I'll keep the list posted. -- Brad

May 16, 2007

Re: [Wlug] large file performance on linux

by Klein, Richard

> -----Original Message----- > From: Jeff Moyer > > p.s. In your head, is Mb Megabit or Megabyte? I always thought that lower-case b meant bit and upper-case B meant byte, but the rest of the world doesn't seem to care what I think. -- Rich

May 16, 2007

Re: [Wlug] large file performance on linux

by brad noyes

On Wed, May 16, 2007 at 11:44:13AM -0400, Jamie Guinan wrote: > On Wed, 16 May 2007, brad noyes wrote: > Hi, > > Do you mean MB/s as in MegaBytes/second? Lower-case "b" implies > "bits" to me, but I suspect you meant bytes. :) > Yes, your assumption is correct. I never quite understood the capitalization conventions when it came to computers. > Anyway, if you know your total data set is going to exceed your system > memory, which will largely get used as page cache, you might as well > open the output with O_SYNC and write straight out. Then the big > buffer in the writer thread can go away, and you can just queue chunks > between the input and writer. > > A good experiment would be to run the writer thread with dummy input > data and see what kind of throughput you get. > > You could try ext2 (no journalling), or tweaking some of the > journalling options in ext3 (data=journal/ordered/writeback, see "man > mount"). > great idea. I forgot about tune2fs and mount options. thanks. > If you have enough CPU bandwidth, and your input stream has enough > redundancy, you could gzip it before writing, which might reduce your > output bandwidth requirements. > There isn't enough redundancy in the data. its essentially random data so it won't compress well at all. > Hope this helps, keep us posted. > Thanks for the input. -- brad

May 16, 2007

Re: [Wlug] large file performance on linux

by Jamie Guinan

On Wed, 16 May 2007, brad noyes wrote: > Hello All, > > I am seeing some really slow performance regarding large files on linux. I > write a lot of data points from a light sensor. The stream is about 53 Mb/s and > i need to keep this rate for 7 minutes, that's a total of about 22Gb. I > can sustain 53Mb/s pretty well until the file grows to over 1Gb or so, then > things hit the wall and the writes to the filesystem can't keep up. The writes > go from 20ms in duration to 500ms. I assume the filesystem/operating system > is caching writes. Do you have any suggestions on how to speed up performance > on these writes, filesystem options, kernel options, other strategies, etc? > > Things I have tried: > - I have tried this on a ext3 file system as well as an xfs filesystem > with the same result. > > - I have also tried spooling over several files (a la multiple volumes) > but i see no difference in performance. In fact, i think this actually > hinders performance a bit. > > - I keep my own giant memory buffer where all the data is stored and > then it is written to disk in a background thread. This helps, but > i run out of space in the buffer before i finish taking data. Hi, Do you mean MB/s as in MegaBytes/second? Lower-case "b" implies "bits" to me, but I suspect you meant bytes. :) Anyway, if you know your total data set is going to exceed your system memory, which will largely get used as page cache, you might as well open the output with O_SYNC and write straight out. Then the big buffer in the writer thread can go away, and you can just queue chunks between the input and writer. A good experiment would be to run the writer thread with dummy input data and see what kind of throughput you get. You could try ext2 (no journalling), or tweaking some of the journalling options in ext3 (data=journal/ordered/writeback, see "man mount"). If you have enough CPU bandwidth, and your input stream has enough redundancy, you could gzip it before writing, which might reduce your output bandwidth requirements. Hope this helps, keep us posted. -Jamie > > Thanks, > -- Brad > > _______________________________________________ > Wlug mailing list > Wlug(a)mail.wlug.org > http://mail.wlug.org/mailman/listinfo/wlug >

May 16, 2007