University Press of New England has donated
http://www.librarything.com/work/6945680/book/39325838
Red Sox Nation Guide to the Players
(They don't publish much in the way of computer books.)
--
Lloyd Kvam
Venix Corp
DLSLUG/GNHLUG library
http://dlslug.org/library.html
http://www.librarything.co
I have a Cell blade that uses NFS for its OS and general storage. I have
written an application that creates and reads large files. The file I/O
is a significant portion of the total execution time. I am trying to
track down several potential sources of slowdowns.
Of course, the first, and p
On Thu, Dec 18, 2008 at 10:51 AM, wrote:
> I have a Cell blade that uses NFS for its OS and general storage. I have
> written an application that creates and reads large files. The file I/O
> is a significant portion of the total execution time. I am trying to
> track down several potential so
bruce.lab...@autoliv.com wrote:
-
What I did find was an asymmetry in read vs write speeds of 2:1. Roughly I
could get 100 MB/sec read over the network, but only 45-60 MB/sec write over
the network. Anyone have an idea why this would be true?
-
Hi Bruce,
You'll want to have a look at th
On 12/18/2008 11:29 AM, Tom Buskey wrote:
>
>
> It seems like you're looking in all the right places.
> I'd suggest running iozone (http://www.iozone.org). That could help
> you map the sweet spot for block size. It will take awhile to run.
This. Raising the MTU to 9000 and using larger block
On Thu, Dec 18, 2008 at 2:25 PM, Mark Komarinski wrote:
> On 12/18/2008 11:29 AM, Tom Buskey wrote:
> >
>
> I'd expect hdparm to be tied closely to PCs with IDE or SATA(?)
> > drives. I know it won't work with SCSI drives on PCs..
> Yes it does: SATA (and IDE I think) disks show up as /dev/sd? de
Six folks attended the December meeting of the Python Special Interest
Group, held on the irregular third Wednesday in December to allow for
the festivities next week. (We normally meet the fourth Thursday, same
place, same time.)
There wasn't a formal agenda, and discussion was first the ice stor
Rats! For some reason I thought this was next week. I've been swamped
between work, finishing the semester and not having power for a few days
(sorry to hear some folks are *still* without). Anyway, sounds like I missed
a decent meeting. Oh well, there's always next month
-Shawn
On Thu, Dec 18, 2
Mark Komarinski wrote:
> The larger MTU means that the CPU (and Ethernet cards) are not losing as
> much data to Ethernet overhead or building the packets. Each packet is
> thus a bit more efficient than a 1500-byte packet.
It might be interesting to change the rsize and wsize to 8k, so that a
Ted Roche wrote:
> documented here [0]. It's an arguable bug; it may be that feedparser
> throws an error instead of behaving more gracefully when hander RSS that
> might not be fully valid, in this case apparently a bad Unicode
> character. Perhaps not fully following Goodwin's Law (paraphrased,
First, read http://h30097.www3.hp.com/tipnfs.html . While I wrote it
for Tru-64 Unix systems, it has a lot of good information for any NFS
environment.
I don't have much experience with NFS on Linux, so my comments will
be more general than useful.
Re: Jumbo frames.
A 1500 byte GbE frame takes a
11 matches
Mail list logo
