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

[Patrick C. <pa...@ty...>]

On Mon, Jan 01, 2001 at 02:48:35PM -0500, Doug Carman wrote:
> Thanks to Steve for the latest patches.  
> 
> 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.
>
> 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.
> 
> With the 12/28 patch, I no longer get "System buffer unavailable"
> messages from RSX, but data is still being lost from Linux->RSX.
> 
> I know there are far more people testing against VMS, so I was wondering
> if anyone else had seen the same problems with VMS?

Just for info (and Steve knows this) I also get the 'hangs' to VMS via ctermd
but no characters are lost. My guess is that it is to do with lots of short
packets being sent. FAL in block mode sends huge blocks of data (32->64K if the
remote end will let it) whereas ctermd sends much smaller packets, I'm seeing
108 bytes each typing a file with lots of 80 character lines).

If I force FAL into record mode then the same thing happens as with ctermd, the
output gets slower and slower until it stalls completely. The blocks here are
not so small as ctermd (4080 bytes) though.
 
Interestingly, my Alpha box (running Phase V) works fine :-)

patrick