Mail To: Jan Krivanek <honza@ov.szt.cdrail.cz>
Subject: Re: STiK/STinG advice for aFTP
----------------------------------------------------------------------------

On 1 May 99, Jan Krivanek wrote:
>On Sat, 1 May 1999 00:50:56 +0200 (MET DST), Ronald Andersson wrote:
>
>   Hi and thanks for previous bugreport.

Hello again, and thanks for responding.


----- snip ----- re: aFTP uploads at 1024 CPS despite 115200 BPS bitrate

>   It's terrible! ;)

True, it is, but now that we have some contact I am sure we can fix it.


----- snip ----- re: The cause of the problem must be lack of information.

>   OK. I have no MagiC, I have no STiK/STinG. I have MiNT+MiNTnet+N.AES
>and I can test STiK versions with help of GlueSTiK. I've got 6kB/s
>on my null-modem line with MiNTnet version.

It may interest you to know that it is possible to run STinG in parallel
with most other TCP/IP stacks that do not themselves use the STiK cookie.
STinG has been used by others in parallel with I-connect, and even with
MiNTnet.  The trick is that you must tell MiNTnet not to use the ports
that will be activated by STinG.


----- snip ----- re: Timing in event loops must not block CPS

>   The timer in event loop depends on CPS and isn't constant in aFTP.

You may be right for downloads, but something certainly does block the
CPS for uploads.  Since I haven't seen your sources I have to guess a
little at the resons for it.


----- snip ----- re: keeping timer events short

>   But short timer in event loop can (and do it) slow down whole system,
>I think.

If used incorrectly, they will indeed slow things down, because the 'evnt_'
functions have a very costly overhead.  With a short timer event as the only
delay function in an event loop, the 'evnt_multi' call may come to be made
very often, each time incurring a new overhead cost.  That will then use up
a lot of the CPU power just to enter and exit the event function calls.

One valuable thing about the _appl_yield function is that it has a fairly
cheap overhead cost. In fact the lowest cost of all AES functions, and yet
it has the ability of keeping other tasks from blocking.

Using this in an inner loop which doesn't exit until a fairly long time has
passed (since a time comparison is part of the loop condition), will stop
the short timer event at start of the outer event loop from being called
too often.  It will only be called equally often as if it had used a long
time constant, and so the overhead costs will be kept down.


----- snip ----- re: using an inner loop with time test condition

>   Hmmm, I call CNbyte_count() function in my get_block() function and then
>I can get every waiting byte. What's wrong with it?

That usage itself is correct.  There is nothing directly wrong with it.

But having subloops for specific purposes, such as 'getting' bytes, means
that other things may have to wait their turn, instead of being handled
in parallel.  The structure I tried to describe can handle both sending
and receiving for multiple connections in parallel, with a minimum of
delay for each.


----- snip ----- re: More on 'inner loop' construction

>   OK, I can try it. I'll send test version to you (soon).

Apparently you did it very soon indeed, as it arrived here in the same mail
batch as your first response did. I will test it at once.

