[Linux-decnet-user] Re: Testing with RSX and latest patches

[Steve W. <st...@gw...>]

Hi,

> 
> Thanks to Steve for the latest patches.  
> 
> I applied both the earlier patch (12/14) and the one from last week
> (12/28) to a fresh 2.4.0-test12 source tree.  I still see packet loss
> when transmitting data packets from Linux->RSX.  When I 'SET HOST' from
> RSX to the Linux system, then perform directory listings or other
> commands that produce output to the terminal, I experience loss of
> output.  
> 
> By running a simple script that generates 1000 numbered lines of output,
> you can see the loss in the output.
>
I've got some ideas to what might be causing this (see below)
[snip]
 
> 
> Eventually, the output hangs and the login must be terminated on the
> Linux system.
>
I've had hangs happen using loopback on my machine here. I actually think
that is a different bug, and I've got a good idea of the cause too. I
think it could be a timer bug (well not the timer itself, but the way it
interacts with the socket locking).
 
> The really bad news is that this problem also appears to affect data
> transfer from Linux->VMS (MicroVAX 3100, VMS v5.5).  In this case, after
> about 30 lines, the output pauses and then continues in small spurts
> until about 70 lines when it stops for a longer period.  During this
> time, it appears that Linux is retransmitting packets and not getting
> ACK's back from VMS.  Eventually, the output hangs to the point where
> the login must be terminated.  However with the VMS scenario, gaps do
> not exist in the output.
> 
What is the program that you are running on the Linux side when you
see this packet loss? ctermd or something else ? I suspect that this
might be a user level problem (maybe the return value from write is not
tested to see exactly how many bytes got written). It is equally possible
that its kernel side too, but we need to find out which and a quick glance
through the source of the relavent program should tell me. Sorry if you've
told me this before and I've forgotten.

> After backing out only the 12/28 patch, I now see reports of "System
> buffer unavailable" from RSX and the output hangs.  From Linux->VMS, I
> get slow output (about 1 line per second) and long pauses in the output.
> 
In this case Linux is sending packets which the flow control does not
allow since the 12/28 patch implements the required flow control
algorithms to prevent this. This is good to know as is means that the
12/28 patch is working :-)

I've sent the 12/28 patch to Dave Miller now but not had any acknowledgement
yet (I guess he is on holiday or something). The other patch is already
on Dave's queue. I guess neither patch will make 2.4.0 now, but it will
probably be in 2.4.1 and I'll send them to Alan Cox for his kernel tree if
he continues to maintain his own kernel patches against the 2.4.xx series.

I'm going to be taking a break from DECnet for a week or so shortly but
I'll keep thinking about solutions to the current problems and try and
have a fix ready to code up when I return,

Happy New Year,

Steve.