So right you are.. I probably remembered the hp100 driver which I had
been fixing for the new skbuff handling. Good. Then the de4x5 should
be perfectly fine (the fact that it works for your 1.2.8 based kernels
doesn't actually guarantee that it works for 1.3.7: in 1.2.8, the
ethernet packet is aligned on a 8-byte alignment, while in 1.3.7 the
ethernet packet is unaligned so that the data _in_ the packet would be
aligned. But looking at the driver it seems it should be fine).
> > Oh, and if you use OSF/1 telnet, you'll notice that out-of-band data
> > doesn't work with OSF/1 binaries (^C in a telnet session will freeze the
> > session, and you'll have to exit telnet with ^]). I haven't looked into
> > it, but I suspect it's due to different definitions for SO_OOBINLINE, so
> > socket options aren't set the way the OSF/1 binaries expect. I'll
> > probably make this binary compatible with OSF/1 as well but I wanted to
> > release 1.3.7 before starting on looking into this.
>
> This is also true of our natively built "telnet" as well... :-(
Ho humm.. I guess I'll have to check this out, then. At least the
OSF/1 telnet _does_ say that it can't do setsockopt (twice, in fact), so
it might be part of the problem, but there might be something else too
(like urgent packet handling not working correctly - I didn't check all
the urg_off stuff for 32/64 bits yet)
> > ttcp gives reasonable numbers for both tcp and udp transfers, but they
> > certainly aren't stellar. Probably because the linux networking isn't
> > _that_ fast, not so much any axp-specific stuff. Anyway, it's not due
> > to alignment issues: the way things are set up now, almost all normal
> > networking headers will be automatically aligned, and unaligned traps
> > are pretty rare.
>
> Our "ttcp" numbers for the DE4X5 were over 1MB/sec, and that with my
> admittedly SLOW checksum routines; I think it depends greatly on the
> quiescence (is this a word? :-) of the net, and the speed of the sender
> and recipient (I got my numbers using a DEC 3000/400 as the other end).
Well, I have a 8-bit ne1000 (yes, not a ne2000, a ne1000) on my i486
here at home, so I suspect that that's a limiting factor. With a better
receiver I'm sure I'd be getting closer to the 1MB/s mark.
However, I actually tested ttcp over loopback as well, and I'm not
getting more than about 2.5MB/s send/receive. That doesn't bode well
for 100Mbps fast ethernet (but loopback is actually more expensive than
ethernet for a lot of reasons, notably one extra copy and both sender
and receiver being on the same machine so you also have the task switch
overhead and no concurrent processing: 2.5MB on loopback could be
equivalent to >5MB over fast ethernet)
Of course, OSF/1 doesn't actually get much better (2.7MB/s), so it may
be just a minor matter of tweaking (and adding the code to do
checksum-while-copying code to the alpha sources). The axp-linux does a
_lot_ of context switches right now, for example (the default time slice
is still set to 15 clockticks, coming out as a whopping 15ms on the
alpha instead of the 150ms it should be ;-)
(Heh, despite that, networking on the alpha actually works better than
on a i386 in 1.3.7 in some respects: there is a x86 checksum bug in
1.3.7 hitting IP packets of length n*4+3 ;-)
> > Oh, to get networking up and running, you'll need axp versions of the
> > linux "route" and "ifconfig". Those are reasonably simple: make sure
> > you have the new kernel header files and check your linker flags (-N
> > doesn't seem to be that good an idea) and they should compile more or
> > less out of the box. I guess I should make my binaries available, duh.
>
> We need to coordinate the new syscall numbers with the libc implementations;
> any chance you'd like to make it public, or is it already "in there"?
I'm using _only_ OSF/1 system calls right now, with the exception of a
few linux-specific system call numbers (bdflush, sethae, mount,
adjtimex, swapoff, getdents and the kernel module syscalls to be exact).
I still think this is the way to go: not so much to leverage on existing
OSF/1 applications (not that many there ;-) as to make debugging easier
for those of us that have both.
"route" and "ifconfig" use ioctls on a socket file descriptor, so they
don't use any new system calls if that was what you were referring to.
Linus