| |
DL9SAU > DPTNT 12.04.04 01:13l 51 Lines 2319 Bytes #999 (0) @ DL
BID : DB0TUDHW13S0
Read: GUEST DL8FBH DG2NBN
Subj: Re: tfkiss - speed > 19200?
Path: DB0FHN<DB0RGB<DB0MRW<OK0PKL<DB0GRL<DB0TUD
Sent: 040411/2258z @:DB0TUD.#SAX.DEU.EU [TCP/IP-NODE DRESDEN] DP6.00 $:DB0TUDHW
do6at@db0abl wrote:
> warum das so ist, weiß ich auch nicht. Aber wenn Du als speed 0 einträgst,
> geht es mit derselben Geschwindigkeit.
michael hatte nicht geschrieben, ob er es auf einer realen seriellen
schnitte oder auf einem unix pty benoetigt.
> Scheint irgendeine Begrenzung in den pseudo-tty's zu sein.
> Nähere Info daruber kann Thomas, DL9SAU geben. Er hat in einer ähnlichen
> Angelegenheit Tests durchgeführt.
pty's kennen aus kompatibilitaetsgruenden saemtliche ioctl's, also auch
das setzen von baudraten.
einen einfluss auf die tatsaechliche uebertragungsgeschwindigkeit hat
die verwendete baudrate allerdings nicht. auch laesst sich pty und
gegenseite mit unterschiedlicher baudrate fahren, und die daten gehen
dabei dennoch nicht kaputt; auch gibt es keinen datenstau.
limitierender faktor bei pty's sind kernel-interne buffer, die diesen
devices gewaehrt werden. d.h. wenn die gegenseite keine daten abholt,
wird die sendende seite irgendwann nicht mehr koennen, und ihrerseits
der sie fuetternden applikation ein -EAGAIN liefern.
stellen wir uns vor, wir wuerden z.B. unser xterm mit auf 75 baud
stellen (um den kernel zu aergern ;) [stty speed 75]
wir stellen fest: die ausgabe ist genauso schnell wie vorher. 75 baud
war die uplink richting eines akkustik-kopplers. den unterschied wuerde
man sehen..
die normale baudrate liegt bei 38400. das ist modemgeschwindigkeit.
waere schon krass, wenn das ein limitierender faktor waere.
zu guter letzt fragen wir uns: wenn wir das tatsaechlich wollten (z.B.
um applikationen auszubremsen). dann muesste man im kernel im pty
treiber eine art traffic-shaper eingebaut haben, der die aktuelle transfer-
rate ueber das pty abschaetzt und limitiert. den aufwand hat aber niemand
getrieben. die idee fand ich dennoch lustig und habe im source nachegschaut -
is aber nich..
dennoch ist die pty geschichte relativ langsam. es wird viel aufwand
getrieben, der typisch fuer eine serielle schnitte ist, damit es sich
eben genauso verhaelt.
bei meinen tests die hardy ansprach verglich ich die durchsatzrate
einer pty-kopplung (wampes<->kernel per kissattach) mit der alternative
tun/tap + bpqether (ax25 ueber den emulierten ethernet layer). letzteres
war deutlich schneller und ist beim bedienen von highspeed-links
dringend zu empfehlen.
73,
- thomas
Read previous mail | Read next mail
| |
