OpenBCM V1.13D (Linux)

Login: GUEST @ JH4XSY.14.JNET1.JPN.AS [Tsuchiura]

Command:
home | newest check | boards | help index | log | ps | userlogin | send sysop | slog | status forward | bcm news | users | version | remove cookie

UT1HZM > 7PLUS    10.04.26 19:36l 27 Lines 938 Bytes #5 (0) @ WW
BID : 41106_UT1HZM
Read: JH4XSY
Subj: 7plus sizes
Path: JH4XSY<JE7YGF<LU4ECL<LU9DCE<VE3CGR<PI8ZTM<IW2OHX<UT1HZM
Sent: 260410/1018Z 41106@UT1HZM.KREM.POL.UKR.EU BPQ6.0.25
Dear 7plus senders!

Can be explained sense of send many-many small sized parts?
On my think - none!

Lets see:

- many small parts create more overhead in total encoded data, for example 100kb
binary or picture file spitted in many 5-kbyte parts will be total size of
~118kb, but spitted in just 4-5 parts will be ~5kb less in total.

- more parts is harder to prosess decode manually, few peoples still do it
old-style, in simple terminal application, by save each message to files and
then run decoder...

- more of small parts really don't regulate BBS traffic on low speed channels!
For example on 1200bd or at HF modes (300baud PR or pactor, vara, adrop etc).
A lot of small parts just blocks a channel for a while and bbs software rule
"send small mails first" not works - because there are tens or even hundred
of "small 7pluses" in queue, hi.

Why not to send 7PL encoded data in not less than 20...25kb parts?!


73,  Sergej.



前のメール | 次のメール