Re: Firewire/USB Card for Qube 2

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

In <223019.61519.qm%web38103.mail.mud.yahoo.com@localhost>
attroppa%yahoo.com@localhost wrote:

> --- Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost> wrote:
> 
> > attroppa%yahoo.com@localhost wrote:
> > 
> > > Speaking of speeds, frequencies and bandwidths
> > seems
> > > that regardless of the speed of the Ethernet
> > adapters
> > > the Qube 2 can not go beyond 10MBits/s speed.
> > 
> > How did you measure the speed?
> > ttcp on my RaQ (not RaQ2) shows:
> > ---
> > # uname -v
> > NetBSD 4.99.63 (GENERIC) #83: Sat May 24 01:56:56
> > JST 2008  \
> >
> tsutsui@mirage:/usr/src/sys/arch/cobalt/compile/GENERIC
> > # ttcp -rs
> > ttcp-r: buflen=8192, nbuf=2048, align=16384/0,
> > port=5001  tcp
> > ttcp-r: socket
> > ttcp-r: accept from 192.168.20.1
> > ttcp-r: 16777216 bytes in 6.39 real seconds =
> > 2562.00 KB/sec +++
> > ttcp-r: 2051 I/O calls, msec/call = 3.19, calls/sec
> > = 320.72
> > ttcp-r: 0.0user 2.6sys 0:06real 41% 0i+0d 0maxrss
> > 0+2pf -15+45csw
> > # ttcp -ts 192.168.20.1
> > ttcp-t: buflen=8192, nbuf=2048, align=16384/0,
> > port=5001  tcp  -> 192.168.20.1
> > ttcp-t: socket
> > ttcp-t: connect
> > ttcp-t: 16777216 bytes in 7.20 real seconds =
> > 2276.17 KB/sec +++
> > ttcp-t: 2048 I/O calls, msec/call = 3.60, calls/sec
> > = 284.52
> > ttcp-t: 0.0user 5.1sys 0:07real 71% 0i+0d 0maxrss
> > 0+2pf -12+51csw
> > # 
> > ---
> > so at least it's faster than 10Mb/s ;-)
> > 
> > > Is it possible that they is not performing up to
> > their
> > > specification because of low bus frequency,
> > > competitions or slow IRQ response?
> > 
> > There is some implementation issue (there are too
> > many extra
> > cache flush, tulip Ethernet doesn't handle unaligned
> > RX buffer etc.),
> > but a slower IDE disk/interface might be most
> > problematic on usual ops.
> > 
> > Some extra kernel options (DIAGNOSTIC, DEBUG,
> > LOCKDEBUG, KMEMSTATS etc)
> > also make kernel much slower, BTW.
> > ---
> > Izumi Tsutsui
> > 
> 
> Sorry for the delayed reply... I did not test with
> ttcp or any other tool. I actually timed the transfers
> when I noticed it is slower than I expected.
> 
> I also did wget of a large file (DVD iso image) from a
> linux box. In the same network (100 MBit switch and
> infrastructure) I managed to squeeze about 11.5
> MBytes/s between the Linux boxes on average (which is
> normal), but only about 750-800 KBytes/s between the
> Qube 2 and a Linux box.
> 
> And that was freezing the kernel at some point when I
> reported it (in our prior exchange).
> 
> Further tests between a Windows box and a Linux box
> the speed in this network can reach only 2.4 MBytes/s
> and it is the winsock and the Windows kernel to blame
> for that, but the funny part is that between a Windows
> (XP) box and the Qube 2 the speed is proportionally
> slower than between a Linux box and the Qube 2.
> Meaning it goes with not more than 350-400 KBytes/s
> real transfer. I will give this credit to Windows,
> because I noticed that the collision packets are very
> often when Windows is involved. Just tcpdump it and
> you will see.
> 
> Puzzling, isn't it? And I do not have time (or
> knowledge) to track the things down the chain for this
> slowdown.

First, Qube2 is much slower than modern x86 machines, and
only "overmuscled" CPUs can saturate 100BaseTX network back in 1999.
For example, the Tulip Ethernet chip can't transfer receive packets
into unaligned DMA buffer and kernel has to copy all RX packets
from DMA buffer to mbufs.

Second, implementation of network stack is too complicated and
we can't see which part (CPU, devices, drivers, VM, protocol layer,
checksumming, etc. etc) has bottleneck without proper benchmarks.

I agree current NetBSD/mips implementation is not so optimized
for MIPS3 CPUS, though.
---
Izumi Tsutsui