[drats_users] D-Rats v0.2.7b2 Latest Version Testing

Dan Smith
Thu Sep 25 14:05:30 PDT 2008


> 1.  First, interruptions will cause immediate failure of transfer
> every time.

Interruptions do not cause failures on simplex.  There is so much
garbage that comes over the wire on the reflector that I imagine some of
that has to do with it.

> 2.  Busy reflectors are a real problem and cause transfer failures
> most times.

I don't doubt this a bit.  Optimizing for the quiescent case seems to be
the most effective thing to me.  Even a small file will take ages to
transfer if the protocol is patient enough to let people chatter while
it's trying to do its work.  I don't really think that trying to inject
such extreme patience is particularly effective.  What do others think?

> Best Results**      '896' Block Size and Pipeline '10'  (defaults
> always failed)        yields 39.48 B/s* ** *
> Worse Results**      '768' Block Size and Pipeline '11'  (    "
> "          "     )        yields 38.43 B/s* *

These settings are effectively the same, so I'd attribute any 
variability to luck or Murphy.

> We used REF001 B with traffic occurring 100% on REF001C, then we used
> REF004 with absolutely no traffic.

100% voice traffic you mean?  I can't see how trying to transfer data 
over an otherwise busy (with voice traffic) reflector is at all 
advantageous for either the voice or data users.

For the quiescent case, the settings that you really want to try are the 
  warm-up and forced delay.  Setting forced delay to 6 (or more) 
seconds, with a warm-up delay of 0 and warm-up length of 64 might yield 
some interesting results.

-- 
Dan Smith
dsmith#danplanet.com, s/#/@/
www.danplanet.com
KK7DS




More information about the drats_users mailing list