>On Tue, 12 Jan 1999, Tomi Manninen wrote:
>> On Sun, 10 Jan 1999, Karl F. Larsen wrote:
>>
>> > TAPR is running scared. Packet Radio even at 1200 baud vhf/uhf or
>> > 300 baud HF is dead in the USA. But it's new stuff in Croatia! People who
>> > were deprived of the experiance in the West are having fun now.
>>
>> New stuff in Croatia. Hmm. Well, Slovenia is close enough. Karl, would you
>> please take a look at http://lois.kud-fp.si/hamradio/prmap.html. Yes,
>> those thick lines really are 1.23 Mbps links. As in 1024 * 1200 bps. Good
>> thing they were deprived, who knows what speeds they would have now
>> otherwise...
>Hi Tomi, I am talking experiance with Croatia. I have friend who uses my
>bbs via the gateway from Croatia. Jimmy lives on the coast and the gateway
>is at a University inland. The link is 1200 baud and gets very slow with
>heavy use.
What bothers Jimmy is a malfunctioning node in his hometown, seems that
noone nearby is qualified enough to fix it so they wait... While it was ok,
they had a 23cm 38k4bps link to the rest of the network.
Truth is, here in Croatia we are using Slovenian solutions for our PR net.
Not because we're neighbours, but because it's in my humble opinion the most
advanced hardware for such purpose - does anyone else even thinks about such
speeds anywhere in the world? And it's all coming from one man - Matjaz, S53MV.
However, linux is not yet ready for such speeds, you can't have efficient
communications at 1M2288bps with present parameter timings. I hope something
will be done about this? I'm talking about at least milisecond resolution, even
present speeds here at the gateway I'm responsible for (38k4bps links) suffer
from 0.1 sec resolution. We're planning to use 1M2 links in the near future,
and there are some "quick and dirty" solutions but it would be nice to have a
full and solid implementation.
While I'm at it, quite some time ago I reported a problem with retry scheme
used in Linux's AX25 implementation, and it was concluded that I was wrong, and
that the problem doesn't exist. The solution was to double the maximum number of
retries and wait... I still do. Let me remind you: when linux starts retrying
(RR+ or RR C P) even if it receives a correct frame in the mean time it doesn't
stop until it gets it's desired one (RR- or RR R F). This is not the case in any
other ax25 implementation I used except Linux. Or this way: try using linux
and i.e. TFPCX with kiss TNC over a lousy and busy link to some non-linux node.
What you get is at least 50% bigger chances to have retry time-out with Linux.
Not a repeated problem report, but a simple question: has anyone else ever
noticed that?
73's...
------------------------------------------------------------------------------
9A4GC: Ivica Smolcic e-mail: [EMAIL PROTECTED]
QTH Sisak, Croatia [EMAIL PROTECTED]
PR-mail: [EMAIL PROTECTED] [EMAIL PROTECTED]
