tomaswolf commented on issue #884:
URL: https://github.com/apache/mina-sshd/issues/884#issuecomment-4006342259

   Well, it depends on the window. The condition to send a window adjust is 
`(size < maxFree / 2 || maxFree - size > 3 * packetSize)`. Here
   
   * size is the current window size
   * maxFree is the maximum window size allowed for the channel, usually 2MB
   * packetSize is the packet size of the channel
   
   If you see window adjustments sent on each packet, that could mean several 
things. Maybe the window is close to having been used up. (Data comes in much 
faster than it is pushed out (by writing to the file).) Or maybe packetSize is 
wrong?
   
   I'd start by instrumenting the code to produce a full log of window 
consumptions and releases. On every consume, log the window before, the amount 
consumed, and the window after. On each release, log `len`, and whether you get 
to line 114. If you do, also log `size`, `size + released`, and for good 
measure `maxFree`and `packetSize`, and whether a window adjust is sent.
   
   Then we'd see how exactly this window evolves over the course of an upload. 
I guess that will tell us what might be the issue.
   
   If indeed we see data coming in faster than it is being written we'll have 
to check if all releases() in SFTP writing are in the right places. (I hope 
they are -- but if for instance somehow we release too late that might cause 
such behavior.) If we find no such problem, we would have to check/log/time the 
actual file writing. Is there a reason that could be slow? Lots of writes with 
offsets that would require repositioning in the file? (That's something else to 
log: actual writes and their offsets. If offsets frequently are non-increasing 
between writes, a lot of repositioning may occur, which makes file I/O slow.)


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to