Hi Vassili,

on Thu 14-10-1999 05:43 Vassilis Papathanassiou wrote:
>on Mon 04-10-1999 07:24 Ronald Andersson wrote:
>
----- snip ----- re: conditions for joining STinG developers group
>
>Just to say (officially ;-) that I agree with all the above conditions.

Fine, then all is clear.


----- snip ----- re: MagicNet
>
>Hmm, during an earthquake brains are also shaking :-))

Well, not too badly I hope, and it seems not, as you could code the stuff.


>>But I certainly want to discuss the possibilities of porting some of
>>that code for use as an alternative STinG interface, possibly through
>>some new dedicated module.
>>
>Well, looking at sockdev driver, I think it can be done. The driver
>just adds a kind of Gemdos functionality to the stack and of course
>it doesn't care what the stack really is. It just happens to contain
>the sockets stuff but I think it can access STinG the way BNET.XFS
>does for example.

That was what I thought too.  One weakness of STinG at present is that
we have no adaption packages for compatibility to alien stacks, whereas
most of them have such for STiK compatibility.  Even Draconis does...
This is what your work could change, so that we too can choose clients
from the whole range available (eventually).  Because once we do have
a MintNet interface for STinG it should be easy to port the adaption
packages of MintNet for the other stacks.  (Except GlueSTiK !  :-)


>>If we share knowledge back and forth in ways that lead to improved
>>functioning of either one or both of these stacks, I see no harm in it.
>>Quite the contrary.  Whichever stack benefits from it, it will mean
>>more and/or better software available for our platform.
>>
>Fully agreed! Btw, MintNet's sources (modified for MagiC) are sitting
>on my hard disk and you can have full access to anything (although
>they're rather huge).

Please send them, size as such never bothered me.  The real problem is
finding time to do all the things that need doing.  But having sources
is never a drawback, even if it is not certain when I'll have time to
work on them.  On the other hand, if I don't have them I don't even have
the option when I do get some time free.

I would also be interested in current BNET sources.  I still intend to
make a BetaDOS driver for BNET eventually, but it could not be done well
previously because of the old limitations of the TCP API.  With the new
modes I think this should no longer be a problem.


----- snip ----- re: debugging under MagiC with PD
>>
>>True, but I do not like the way PD does some things, though I will
>>have to live with it until something better comes along.
>>
>Sure, (like a multitasking debugger for example ;-) but the point is
>that PD works OK most of the time (probably because no MagiC version
>comes out without compatibility with it) and it also works under
>MagiC PC ! (a bit problematic with high color but still usable).

Good points, but I wish we had something as powerful as AMON for MagiC,
so that we could trace interrupts and such stuff too.


----- snip ----- re: debugging from PC.PRG environment
>
>Well, I don't think PC.PRG is 'pure crap' but also I haven't seen
>PC_SHELL 2.21. I had used an old version for a night ;-), found it
>interesting (but in German) and lacking some options I'd like
>to see. Thus I've abandoned it.

Well, to each his own I guess.  I simply can't stand the editing
commands in PC.PRG, so I have to use another editor to keep from
going crazy...  :-)   And PC.PRG will not allow me to do that  :-(


----- snip ----- re: using PD breakpoints in STX modules run as APPs
>>
>>*IF* the multitasking survives such a breakpoint, which is dubious
>>in most kernel tests, and some module tests where problems develop
>>in interrupt-driven parts.
>>
>*YES*, multitasking survives such breakpoints (most of the time TBH)
>and one can get *very* useful results (provided a large monitor or
>resolution is used, otherwise it can be painful to use).

I know.  It is usually necessary to inspect not only code and CPU state,
but also several different memory blocks, to keep track of what's happening.
In a low rez, that can get very awkward.


>>Not for me.  Many of my own sources are in DevPac form, and PD is
>>really only good for showing PASM/PC stuff properly. I have to settle
>>for seeing a raw disassembly of the code.  Not that this is any real
>>problem, as that is what I am used to with other debuggers too.
>>
>You're right of course that it's not so useful with assembly programs,
>even the ones written using PASM. But it's really great for C apps,
>especially for examining structures.

Maybe, but even there it has some odd quirks.  Like when I loaded an APP
compiled with debug info, wanting to trace its startup.  Forget it ! Not
a chance.  PD autoruns the APP until it reaches 'main' and I have no way
to see what happens before then, and if that part crashes it's bye-bye...

It doesn't even tell me where the program's basepage is, and there is no
way I can see that from the address of 'main'.  So I tried to check the
'p_run' variable, but again no luck, there I only find the basepage of
PD itself.  All in all, another completely useless test thanks to PD !  :-(


----- snip ----- re: more on breakpoint methods to avoid timeouts
>
>Or (the method I normally use) using conditional or count breakpoints.

I am not very familiar with those as used by PD, as my greatest need is
to trace interrupt driven code, and for that PD is not even an option.
Only AMON is capable of doing that, and only under singleTOS.


----- snip ----- re: Timer C routine specific to usage as such
>
>Yep, I've seen it now, it's not so hard to adapt it anyway, and I might
>do it if my searching in TCP code fails (see my other mail for details).

It can be adapted, though not as easily as modules, but my point was that
all results with such an adapted routine would be dubious.  They might
not at all match what would happen when installed as usual.


----- snip ----- re: implementing network events for GEM
>
>I hope you'll find a generic solution but IMO multitaskers behave very
>different than Singletaskers when such methods are applied.

True, so the only hope of success is to attack precisely those points
that they all must copy or emulate from singleTOS to maintain their own
compatibility.  One such point is the basic methods used for the GEM
trap, and its relationship to etv_setcritic. NVDI itself is dependent on
that, and no modern GEM multitasker will risk losing NVDI compatibility.


>The only
>solution I can see is that the system should provide the method for
>doing such things (MiNT is doing it already), at least to save us the
>trouble to build a multitasker inside the multitasker and block the
>system in super mode for long periods.

The latter should of course be avoided where possible, but I think there
are many ways open to achieve these improvements, without going the way
of MiNT.


>>That is one of the main differencies between getting timeslots this way
>>and getting them from timer C interrupts. The difference between regular
>>and irregular timeslot use can be crucial for efficiency, as Peter and I
>>found when developing the current STinG methods (it was a joint effort).
>>
>I don't think I agree with that, TCP/IP and Co are highly asynchronous in
>operation and timeslot irregularity can't cause trouble within reasonable
>limits. For precise timing, timer C is always available anyway.

Unfortunately we can't expect reasonable limits from GEM multitasking.
We might experience intervals of no timeslots lasting several hundred
milliseconds, depending on what other APPs do, and that would affect
the efficiency severely.  As for using timer C for precision timing,
that can only be done from an APP when it has been given a timeslot.
So the precision is only available for comparison, not for execution.


>I-Connect and Draconis (to name just two) are both using evnt_multi() with
>good results.

Maybe, but only with great dependence on other APPs. There are many things
those could do that would halt the networking, which I find unacceptable.

With STinG methods networking seldom halts even if the system as a whole
crashes, and there is no normal operation an APP can use to affect it.
Of course, servers and clients may be crashed, but the system usually
continues to work as a gateway, which can be important at times.


>MiNT is using the VBL for MintNet and task switching, and you
>can't be sure (thanks to their 'methods') that you'll get exact time slots
>(it depends on the load). But (TBH ;-) they also use the gem timer to
>update sockets timeouts, so in that case you can be sure that something
>will 'expire' almost with precise timing (thus even the retransmition
>problems can be handled).

I haven't studied MiNT sources lately, so I am not up to date on the methods
they use, but I am not surprised they found VBL insufficient.  That is even
dependent on the screen resolution and monitor type, and as such it is not
a serious alternative to handle network timing.  In fact there is only one
thing in a standard Atari system that is, and that is the Timer C interrupt.


>Please note that it's highly possible I'm missing something here, for the
>moment this is the impression I've got from my searching on the subject.

You are probably correct, though I think you underestimate the benefits of
using timer C.  We may want to restructure some things and redistribute
some of the workload, but I can't see STinG working well without some
timer C interface.


----- snip ----- re: no APP STinG version  ;-)
>
>Ok, ok ;-) let me explain. I've never talked about an APP STinG version!
>I've only talked of a device driver (in the past) or a 1-2KB APP (lately)
>dropped into MagiC's START folder for timing purposes. And this IF and
>only IF we have agreed (with hard evidence) that there are unsolved
>problems using the current method under MagiC.

I suppose I could live with that, but we'd have to have specific details
on those problems then, which at present we don't.  The major problems
MagiC does have today seem unrelated to STinG.  (At least to me.)


>I also have my reservations for evnt_multi's usage and for the moment I
>have nothing to back it up. But on the other hand I think that doing
>everything in one go (ie poll_ports which receives, analyzes, sends and
>possibly cleans up) can cause trouble, since it can take a lot of time,
>especially when a lot of connections are active and several physical
>interfaces have to be accessed.

That is what I meant about possibly redistributing work.  But there are
also benefits from doing it the current way.  We know the sequence that
port work is performed in, and that they will never interfere with each
other this way.  That is lost if they are separated from the other stuff
in the present timer C code.


>Anyway, we can leave it for the moment, until we have something more
>on the subject. I've told you before that I have no problem with the
>current method as long as it does what we expect it to do.

Good.  We can get back to this later then.


>I have to say here that during a MagiC crash on my TT (** Fatal error
>in Gemdos ** System halted ) I was able to access the Internet from
>MagiC PC AND the PC itself (through ethernet) without problems (!!!),
>ie STinG was still alive, so the current method can't be that bad :-)

And I have tested the same kind of crashing under MultiTOS, Geneva,
nAES, and of course singleTOS too, and it works the same way there.
With variations of course, as a severe crash can lock even timer C,
though that happens very rarely.

This is really a unique property of STinG, as even MintNet goes all
to pieces if anything happens to Gemdos. And a stack dependent on APPs,
such as Draconis etc, would of course be much more sensitive than that.


----- snip ----- re: avoiding multiple STinG versions
>
>That is accepted of course, but I see nothing wrong in checking a cookie
>to see if this or that are available and acting accordingly.

Sure, but preferably this should not duplicate large parts of the code,
as that would soon grow very difficult to maintain.  For example, it is
not a good idea to have MagiC TCP routines unrelated to those used with
other systems.  But to have some small portion of it that handles some
specific detail in a special way for MagiC, that would be acceptable.


----- snip ----- re: problems with SERIAL.STX under MagicPC
>
>I don't know either, maybe the driver is wrong (or not complete) in
>that it needs Fread/Fwrite and not the equivalent to Bconin/Bconout
>that SERIAL.STX currently uses. I-Connect and ConNect can use it
>without problems and I'd like to have a look to SERIAL.STX and make
>it compatible too (if possible).

I suppose that would be ok, though I myself am not very familiar with
it yet (not at all actually).  Just remember that this is not just a
port driver.  It also contains all the code for PPP, PAP, and VJHC.


----- snip ----- re: preferred quote 'snipping' methods
>
>You're right of course, as you can see, I've already done this for parts
>that I completely agree.

Good.  One of the reasons for my way of snipping is that I often save only
outgoing mails, and let those constitute a complete record of the dialog.
The exception to that rule is of course when there are large code examples
that need to be saved out separately before snipping.


>Only a (possible) hint here. Peter's sources for ethernet were exactly
>as you describe them, I've used QED to turn spaces to TABs with very
>good results (and then changed the rest manually).

Actually I prefer to not do this with some global editing, because this
way I am always aware of which routines I have not yet analyzed properly,
as I usually do this while reediting them.  It increases the work, but I
really believe that I digest the stuff better this way.


As you may have noted over the last week, there have been a lot of changes
in the TCP module, and some more are needed, and for both it and UDP I will
change the E_DEFERRED message to E_LOCKED in the next betas, as a result of
the discussion with Dan.  If you wish I can send you the current sources,
but they will not be stable, as I have a bug to fix urgently.  I'd prefer
to send you the new sources after that fix as those should have a chance
of staying stable a little longer, while I study other problems.

I'll send you the SERIAL.STX sources now anyway, that you asked for above.

-- 
-------------------------------------------------------------------------
Regards:  Ronald Andersson                  mailto:dlanor@ettnet.se
http://dlanor.atari.org/    ICQ:38857203    http://www.ettnet.se/~dlanor/
-------------------------------------------------------------------------
