[nos-bbs] Discussion about JNOS 'slowness' ...

[Michael Fox - N6MEF]

Thanks Maiko!

For me, I think I'll wait until the timers "behave".

I never bothered me before since most users are on serial and I attributed
the lag to serial transfer time.  But yes, for the places we use LAN
connections, it was noticeable, but not terrible.

What DOES continue to bother us is unreliable forwarding with FBB stations.
Right now, this is a problem over Telnet.   When trying FBB 1, I get the
protocol errors that I've reported before.  

When using FBB 2, there are other "mysterious" problems.  Others have told
me that FBB 2 works o.k. over the air.  You've previous posited that it
might be due to Telnet receiving escape characters due to the FBB 2
compression.  You gave me a suggestion to edit the telnet code and
recompile.  This, as I understand it, would have affected all telnet, so I
wasn't keen on trying it.  (I suppose I could on a test system, but not on
our production systems).

So bottom line, FBB 1 seems to have a protocol-level error in it and FBB 2
doesn't work properly via Telnet - particularly if JNOS telnets to FBB. 

Do you have an FBB station you can try this with?  If not, perhaps I can ask
one of the FBB station owners that I forward with to allow you to forward
with him so you can see things first hand?  If not, I could work with you to
send tcpdump/wireshark traces back and forth.  I'm hoping you can find the
time to work on that...?  (That's my Christmas wish!)  ;-)

Michael


-----Original Message-----
From: nos-bbs-bounces at tapr.org [mailto:nos-bbs-bounces at tapr.org] On Behalf
Of Maiko Langelaar
Sent: Thursday, December 27, 2012 4:10 PM
To: NOS BBS Mailing List
Subject: [nos-bbs] Discussion about JNOS 'slowness' ...


First of all, I hope everyone had an okay christmas. As well, I would like
to wish everyone the best for the upcoming new year.

Has JNOS always been 'slow' ?

This might be hard for me to explain, but when you are connected to a JNOS
station and you hit enter to send a command, you may have noticed it might
take a 'second' for it to be 'processed'. It's not a lightning fast response
time is it now. I noticed this while trying to connect to my own JNOS via a
3 'wire' led/phototransistor dummy serial load (bounces data right back at
the same interface). And to be frank, I've noticed it in many other
occasions. Forwarding should never take so long, netrom is always painfully
slow, and so on.

Was it always like this (for the linux version) ?

Or did this start happening back when I did the kernel change, back when I
was somewhat forced to use the setcontext() functions instead of setjmp()
calls and such. Version 2.0e and earlier use setjmp() methodology, 2.0f and
older use the setcontext() functions.

Was the DOS version the same too ?

SOOOO - Want to see JNOS go like lightning ? It's easy enough :

    edit timer.h, change MSPTICK to 1 (normally it's 55)

    rm domain.o main.o rspf.o timer.o unix.o

    make

CONSEQUENCES - your timers will expire much faster now, but the system clock
will be fine. But as an experiment, give it a try, tell me what you think.
Not sure if this was always the way it was, perhaps due to inadequate CPU
for it's time, I don't know.

I'm going to play with this a bit, a patch will be released in the near
future so that the timers behave, but JNOS will suddenly come to life !

I've known about this for some time, but my experimenting that I've been
doing over the christmas holidays kinda brought it up again. Never thought
how noticing the delay between laser diode flashes can refresh one's memory
on the topic.

Maiko Langelaar / VE4KLM

_______________________________________________
nos-bbs mailing list
nos-bbs at tapr.org
https://www.tapr.org/cgi-bin/mailman/listinfo/nos-bbs