login::
pass::
name::
id::
node:
thus spoke juraj in 'prioritizacia
trafficu'
template:
4
parent:
thus spoke nudzo in 'prioritizacia
trafficu'
owner:
juraj
viewed by:
created:
12.05.2004 - 12:18:32
cwbe coordinatez
:
101
63540
63542
2109677
63692
811496
812627
812982
ABSOLUT
K
YBERIA
permissions
you:
r,
system:
public
net:
yes
так
neurons
stats
|
by_visit
|
by_K
source
tiamat
K
|
my_K
|
given_K
last
commanders
polls
total descendants::
total children::1
show[
2
|
3
]
flat
ale to MUSI stracat packety, kedze je tam stochastic fairness queuing.inac ten konekt neoshapujes. kebyze tam mas zavesene tbf, tak mas obrovsku queue a s latenciou si uplne mimo.
title/content
title
content
user
000001010006354000063542021096770006369200811496008126270081298200813309
nudzo
12.05.2004 - 13:43:12
, level: 1,
UP
NEW
thus spoke nudzo in 'prioritizacia trafficu'
Hej, hej... mne je to jasne... som s tym dost dlho spekuloval... sak mne islo hlavne o to sfq... aby rychly connect neprehlusoval ostatne. Len ono to dostavalo TCP connecty sporadicky do takeho stavu, ze casom zakapali... proste sa stratil nejaky kontrolny/potvrdzujuci packet a TCP connect ostal vysiet v cudnom stave a casom skoncil s timeoutom... bolo to tak, ze druha strana ostala posielat ACK o doruceni paketu, ale localna cast uz nejak MFP... Nikdy som nezistil, co bol za problem... Hlavne windozov bol prob.
BTW pre sfq sa musis vzdat casti pasma... aspon malej, lebo potom sa neuplatnuje... cize napr. ked mas 256kbps, tak treba cez cbq alebo htb shape na cca 253kbps a za to sqf... inac sa ta queue neuplatnuje... No a u mna je to momentalne prob., kedze obaja provideri su 1Mbit a garantovanych 512kbit... takze to vzdy lieta medzi tymi dvoma hodnotami a je dost tazke si najst kompromisnu hodnotu aby som to trosku osejpoval ale vela neukrojil... :-(