| eeh@netbsd.org wrote:
|
| [...]
|
| > You seem to have 22% idle time left, assuming this snapshot is pretty
| > accurate overall, so you don't seem to be CPU bound.  So, unless your
| > test program is single-threaded, where the processor is waiting for
| > a response across the network, this seems to be limited by the speed
| > of the ethernet controller.
| > 
| > Eduardo
|
| So.. ~2.5 MB/s is the maximum available with SS20+hme's? Very
| interesting.

It's difficult to say from that particular info.  The controller
could be limited by SBus bandwidth, memory bandwidth, or ethernet
congestion.  Since the HME driver does not take advantage of the
hardware checksum generation, that could also be part of the problem.
However, it does not appear to be specifically CPU speed limited in
the most classic sense.

| Does someone have the patches Martin talked about a bit earlier?

Those patches are for zero-copy TCP output.  Since you are not
CPU limited, they probably won't help all that much.

| Seems like a good moment to test them.. The snapshot should be accurate,
| I waited pretty long for the numbers to settle.

I generally prefer `vmstat 5' which gives a better view of performance
over time and lets you see fluctuations as well.

| FWIW, I can do the testing with both SS20 and Ultra-1, if needed.

Let's see...   First of all, do you have any other traffic on that
link?  Is the file you're using for testing being transmitted from
the machine, to the machine, or is the machine a mere bridge?  You
should also check to make sure the HMEs are running full duplex.  
There were some bugs in that area that were recently fixed in -current.

I would start by copying from /dev/zero across the network as a 
baseline and see how the machine performs.  You should either get
zero idle time or end up limited by ethernet bandwidth.  If neither
of those happen we'll have to take a much closer look at the driver.
Also check the driver for errors or collisions.

Eduardo