On Wed, Mar 05, 2008 at 06:59:53AM -0800, David Lee Lambert wrote:
> On Feb 29, 6:11 pm, "Ty! Boyack" <[EMAIL PROTECTED]> wrote:
> > David Lee Lambert wrote:
> > > I have an Ubuntu Gutsy system (using the open-iscsi 2.0-865 package)
> > > connected to a LUN on a NetApp filer.  When a single process is
> > > reading data from the filer,  I get about 4 MB/s read speed;  when two
> > > processes are reading data,  each process gets at least 20 MB/s.
> >
> > I'm not quite in the same hardware situation, but I've seen similar
> > slow-downs with the default read ahead buffer on the iscsi devices.
> >
> > At least on fedora, the default read ahead buffer is 256 512-byte
> > blocks.  You can see this number with: [...]
> I tried setting higher values of the readahead parameter.  I do get
> better read performance for a single large file with a sufficiently
> high value,  but performance reading a directory-tree is still
> terrible.  I also measured smaller values;  there are some values of
> readahead for which performance is twenty times worse than what I was
> complaining about (200k/sec !), but for 7 sectors or less I actually
> get better performance (15 MB/s) than the other system (10 MB/s).
> I've posted my data and graphs at
> http://www.lmert.com/download/santest/
> Over the range from 0 to 250 sectors,  another system exhibits
> increasing performance, topping out at 70 MB/s.  Thereafter,
> increasing readahead only gives a very slight improvement.
> Over that range,  the system I'm worried about gives terrible
> performance for many values.  It's hard to see on the graph,  but
> there is actually a plateau of 40 MB/s right around 180 sectors;
> another of 6 MB/s around 256 sectors; and 14 MB/s at 0 sectors.  The
> speed is repeatable (with about 10% variance) at any particular value
> of readahead.
> Going in the other direction,  readahead in the range of 1000 to 2000
> gives over 40 MB/s reading a single large file,  and does not show
> regions of really low performance.  This would meet our goal if we
> wanted to back up single large files to tape,  since that seems to be
> our tape drive's maximum write speed.
> However,  raising the readahead does not improve performance tarring
> up a directory containing subdirectories and small files as much as we
> would like.  It gives a two- or three-times improvement,  but I still
> got a maximum speed of 13 MB/s,  while the other system can do tar at
> 70 MB/s as well.
> FInally,  I've done testing of raw TCP and IP performance between the
> two hosts using back-to-back netcat and "ping -f".  There's no packet
> loss between the hosts,  and I can push 70 MB/s in one direction and
> 55 MB/s in the other.  "ping -f" reports about 60% packet-loss going
> to the NetApp from either host;  I don't know whether that's
> significant.
> The system that works acceptably has a 3 GHz CPU, 1 GB of RAM, and an
> Intel 82572EI network adapter.
> The system that has problems has a 2.4 GHz CPU, 512 MB of RAM, and a
> Linksys adapter (uses the r8169 driver).

Is it possible to try with a different NIC? 

Intel e1000 and tg3 are the "safe" and good choises.. r8169 isn't much used
in the servers, so I don't know how well it works or performs.. 

-- Pasi

You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi

Reply via email to