On Wed, 13 Jan 1999 [EMAIL PROTECTED] wrote:
> >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?
Yes...
I sent a detailed report of this problem (with listen dump) a little of
time ago.. I had only 1 answer... Anyway, the problem is still there and i
get TOO many rejects after the first reject even if i have a good link
Luca
>
> 73's...
>
> ------------------------------------------------------------------------------
> 9A4GC: Ivica Smolcic e-mail: [EMAIL PROTECTED]
> QTH Sisak, Croatia [EMAIL PROTECTED]
> PR-mail: [EMAIL PROTECTED] [EMAIL PROTECTED]
>
--------------------------------------------------------
Luca Palazzo -------------------------------------------
Ingegneria Civile - Universita' di Catania -------------
Email address : [EMAIL PROTECTED] --------------
--------------- [EMAIL PROTECTED] -----------------------
Ham addresses : [EMAIL PROTECTED] --------------
--------------- [EMAIL PROTECTED] --------------
--------------------------------------------------------
Home Page ------> http://genius.cdc.unict.it/~lpala ----
- Under Construction ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ----
--------------------------------------------------------
------- Visit our local Ham Association Web Site -------
------- http://www.ham.cdc.unict.it/~lpala/arical ------
--------------------------------------------------------
