[SLO-TIME] Stabilnost relativne frekvence

Fri Jul 4 12:16:24 CEST 2003

On Fri, 27 Jun 2003, Mark Martinec wrote:

> Obe zadevi sta ze nekaj casa podprti, najbolj obsirno razlozeno v
> man pageih: Broadcom ethernet: bge(4); od FreeBSD 4.5 naprej,
> Rocketport serijska kartica: rp(4); driver napisan pod pogodbo s Comtrolom.

Aha. Bom potem verjetno preizkusil se obnasanje pod FreeBSD.

> Ne vem kako je sedaj s tem, ampak vsaj pri nekaterih verzijah se ni dalo
> spustiti minpoll pod 'tinker minpoll' vrednost, ki je normalno 6.

To zdaj ne bi vedel. Sem takrat vpisal tudi tisti 'tinker minpoll'.

> | Ce kaksna dobra dusa zna pojasniti, zakaj je strelovod iz zornega kota
> | vseh treh vcasih (sicer v manjsini primerov) tako neverjetno hiter (nizek
> | RTT), bi bil vesel razlage.
>
> Ne znam. Pri nas najdem 0.25 ms RTT, manj pa ne - res pa nisem
> gledal med najhitrejsimi masinami.

strelovod tukaj vsekakor ni najhitrejsa masina. Izrazito najpocasnejsa je
sicer mira, ampak potem pa je ze strelovod tam nekje, ce stejemo od
pocasnih navzgor. Morda je se peci pocasnejsi od njega.

> | pricakovani razmazani piki. No, koncentracija pik okoli izhodisca je
> | sicer precej vecja od tistih bolj dalec vstran, kar na tej sliki ni
> | najbolj razvidno.
>
> Vertikalni zmazki so posledica nihanja frekvence lokalnega oscilatorja,

Sem pripravil se nekaj slikic, ki prikazujejo koncentracijo pik na
posameznih mestih grafa. In glede na njih situacija kot kaze vendarle ni
tako huda. Gre za slike ps3-?.png na strani <http://delta.uni-mb.si/ntp/>.
Vse prikazujejo stanje omege, kot jo vidi tartuf. Podatki so isti, kot na
ze znanih slikah. Vse tri slike pravzaprav prikazujejo isto stanje v
razlicnih merilih. Pike so tukaj po razredih (barvah) razdeljene tako, da
je stevilo pik v vsakem razredu priblizno enako. Razmere, kjer so
velikosti razredov enake, pa so prikazane na slikah ps3a-?.png. Sploh te
slike dobro prikazujejo, da je zgostitev pik v srediscu veliko vecja in
ostrejsa od tistega, kar si clovek misli glede na prvotne slikice.

Poskusil sem tudi s 3D grafi, kjer bi namesto barv vpeljal tretjo
dimenzijo. Pa mi ni uspelo spacati prav nic lepega. :-/

> Do neke mere se jih da kompenzirati s povecano pogostnostjo NTP paketkov,
> a pod 16 sekund se tega ne da spustiti.

To sem ze imel.

> Potem ti preostane le izbrati stabilnejsi frekvencni izvor
> (TSC/i8254/ACPI) ali caranje s temperaturno kompenzacijo.

To bom vsekakor dodal k testom, ki bodo verjetno narejeni s FreeBSD.

> Gotovo pomaga tudi PPS signal, a s tem se nisem igral.

Kako bi to fizicno povezal. PPS signal iz GPS sprejemnika preko adapterja
povezem na poseben serijski port? Ali je to potrebno nekak dodati v
obstojeco serijsko povezavo z GPS sprejemnikom?

> Nestabilnosti v routingu?  ARP timeouts / ARP query?
> UDP redirect od routerja ko pade IP iz ARP tabele?

omega in tartuf sta prikljucena na isti switch. Sta pa res v razlicnih
VLANih, vendar routanje med njima opravlja samo en router (v bistvu modul
switcha). Zato dvomim, da bi tukaj lahko slo za kakrsnekoli nestabilnosti
v routingu.

ARP? To bi bilo mozno. Vprasanje je potem sicer, zakaj se to ne pojavlja
prav nikjer drugje.

Za UDP redirect dvomim. Ne uspem si namrec zamisliti situacije, kjer bi en
streznik poslal paket routerju, le-ta bi pa mislil, da bi ta paket lahko
strezniku poslal komu primernejsemu in bi mu to poskusil dopovedati z UDP
redirectom.

Mi je pa prisla na misel ena stvar - MLS. Switch in router se namrec
gresta MLS, kjer se na switchu ustvarijo doloceni podatkovni tokovi, kar
pomeni na *sam* switch posreduje pakete tudi med razlicnimi VLANi, dokler
gre za pakete iz podatkovnih tokov, ki jih ima v svojem cache-u. Seveda pa
podatkovni tokovi vsake toliko casa "padajo" ven iz cache-a, kar pomeni,
da naslednji paket mora do routerja in nazaj, kar spet ustvari podatkovni
tok. Toliko na kratko. Gre v glavnem za to, da vecina paketov gre po poti
server->switch->server, nekateri pa
server->switch->router->switch->server. Vprasanje je tukaj spet, zakaj se
to ne pojavlja pri drugih kombinacijah streznikov.

Ce kdo ne pozna MLS in ga zanimajo podrobnosti, priporocam branje recimo
<http://www.cisco.com/univercd/cc/td/doc/product/lan/cat5000/rel_5_2/layer3/mls.htm>

> RTT v LAN je predvem odvisen od hitrosti masin in njihovih
> Ethernet vmesnikov.

Omega in tartuf imata sicer 1 Gb/s Ethernet vmesnik, vendar sta
prikljucena na 100 Mb/s port switcha. Mira ima 10 Mb/s half duplex
povezavo do prvega switcha (kaj vec pac ne zna). Vse ostalo pa je povezano
s 100 Mb/s full duplex povezavami na switche. Oni "mirin" switch je na
hrbtenico povezan preko 200 Mb/s FastEtherChannel povezave (dve 100 Mb/s
liniji zdruzeni), vse ostale povezave med switchi so 1 Gb/s.

Pred casom sem dodal opcijo "prefer" za omego na tartufu. Tako nastali
sliki delujeta precej lepse od starih: pst-a.png in pso-a.png.

Vceraj sem na omego instaliral 2.4.20-NANO verzijo kernela. Pravi vtisi
zal niso nic kaj dobri, ampak naj zadeva nekaj dni tece. Za pokusino
vcerajsnji graf relativne frekvence za omego na sliki ls-a.png. Ob tistem
velikem skoku je bila instalacija novega kernela in kar precej rebootov
zaradi testiranja necesa drugega. Kasneje pa vse izgleda tako, kot bi se
stabilnost frekvence glede na stari kernel poslabsala. :-(

Lep pozdrav,
		Ales

-- 
Ales Casar                |  Email:    casar at uni-mb.si
Computer Centre           |  DECnet:   RCUM::ALES
University of Maribor     |  AX.25:    S56SAC @ S50MBR.SVN.EU
SLOVENIA                  |  WWW:      http://www.el.feri.uni-mb.si/~ales/