ADSL:n Upload keskim. nopeuden seuranta

[Juha L.]

Sukulaiseni firmassa on pienimuotoinen serveri, jossa pyöritetään
Windows-pohjaisia materiaalihallinnon ohjelmia. Serveri kiinni 8/1
ADSL-linjassa, toimittaana DNA.

Kahdesta sivukonttorista otetaan yhteyksiä tuohon pääkonttorin
koneeseen. Tämä etäkäyttö menee armottoman hitaaksi ajoittain. Yhden
tuotteen hakeminen kestää 15 sekuntia tms.
Suurin epäily on että serveripäässä ADSL:n 1 megainen Upload linjan
tosiasiallinen, tehollinen nopeus olisi se rajoittava tekijä.

Kahdelle uusissa tiloissa toimiville sivukonttoreille saa vaikka
valokuidun tilattua. Mutta pääkonttori ja sen serveri ovat melkein
maalla. Liki 5 km päässä puhelinkeskuksesta, eikä linjanopeuttaa sinne
pystytä ainakaan ADSL:llä teknisesti nostamaan.

Serveripään tietoliikennepiuhat ovat DNA:n hallussa, ja heidän mukaansa
Upload-nopeus olisi heidän mukaansa 0.9 Mbit luokkaa.

Mitään mittaustuloksia tai menetelmiä DNA:lla ei kuitenkaan muka ole
osoittaa tai käytettävissään. Eivät pysty linjan seurantaohjelmilla tms.
osoittamaan koko työpäivän ajalta, että millainen määrä dataa
serverikoneen Upload-linjassa liikkuu.

Eivät osaa sanoa onko se linja suuren osan aikaa tosiaan täydessä
liikenteessä ja tukkeessa. Itse epäilen että joidenkin häiriöiden vuoksi
pitkä 5 km linja ei anna lähellekään 0.9 Mbit nopeutta tasaisesti.

Kysymys kuuluu, millaisilla ohjelmilla voisi itse koettaa kerätä dataa
tuon ADSL-linjan uploadauksesta? Jonkinlaista jatkuvaa seurantadataa,
että miksi linjayhteys ajoittain menee aivan hitaaksi matelemiseksi.
Näkisi että kulkeeko linjalla sen tukkeen aikana tosiaan 0.9 Mbit tuutin
täydeltä, vai kulkeeko siellä vain puolikas tuosta tai sen allekin.

Serverikoneet ovat Windows-koneita, ja ADSL-purkit jotakin mahdollisesti
Telewellin tai TP-linkin tms. peruspurkkeja.

Mikähän järjestely näissä toimisi? Onko seuranta helpompaa
Serveripäästä, vai kannattaisiko seurata kuitenkin Työasemien päästä?
Suht kevyellä ohjelmallisella overheadilla saisi toimia, ettei se
seurantaohjelma ala sitten jo haukata merkittäviä tehoja Windowsistakin.
Tai ettei se vie omaa osaansa ADSL-linjan kapasiteettia.

J.L.

[upsid...@downunder.com]

On Sun, 11 Aug 2013 11:37:12 +0300, "Juha L." <not-w...@none.fi>
wrote:

>Sukulaiseni firmassa on pienimuotoinen serveri, jossa pyöritetään
>Windows-pohjaisia materiaalihallinnon ohjelmia. Serveri kiinni 8/1
>ADSL-linjassa, toimittaana DNA.
>
>Kahdesta sivukonttorista otetaan yhteyksiä tuohon pääkonttorin
>koneeseen. Tämä etäkäyttö menee armottoman hitaaksi ajoittain. Yhden
>tuotteen hakeminen kestää 15 sekuntia tms.

Onko serverin lokeista yms. nähtävissä sekä kysely että lähetetyn
vastauksen aikaleimat ? Tästä ainakin voi varmistua siitä, ettei
serveri itse jumita liikennettä.

Jos kyseessä on yksinkertainen yksisäikeinen serveri, joka käsittelee
yhden pyynnön alusta loppuun ennen uuden kyselyn käsittelyä, tällöin
vastausten kuristus alhaisen upload nopeuden takia näkyy siinä, että
seuraavan kyselyn käsittely alkaa vasta edellisen vastauksen saatua
toimitettua TCP putkeen. Tämä on helposti todettavissa rinnakkaisella
puhelinyhteydellä, jossa kyselyn lähettävä henkilö kertoo kyselyn
lähetyksestä ja seurataan serverin samanaikaisesti lokista, koska
kyselyä alettiin ihan oikeasti käsittelemmään.

Varmimmin tuota voisi tutkia tcpdump kaltaisilla työkaluilla, jossa
voisi katsoa kuinka isoja ikkunakokoja clientti julkaisee, eli kuinka
pienissä paloissa serveri joutuu lähettämään vastauksensa.
Valitettavasti näiden lokien tulkinta on varsin hankalaa.

>Suurin epäily on että serveripäässä ADSL:n 1 megainen Upload linjan
>tosiasiallinen, tehollinen nopeus olisi se rajoittava tekijä.
>
>Kahdelle uusissa tiloissa toimiville sivukonttoreille saa vaikka
>valokuidun tilattua. Mutta pääkonttori ja sen serveri ovat melkein
>maalla. Liki 5 km päässä puhelinkeskuksesta, eikä linjanopeuttaa sinne
>pystytä ainakaan ADSL:llä teknisesti nostamaan.

Jos kerran tämä on tilanne, miksei serveri sijaitse jommassa kummassa
sivukonttorissa (tai kalleimmassa tapauksessa webbihotellissa) ?

Hidaskin modeemi/GPRS yhteys varmasti riittää yksitäisten tietojen
päivittämisen pääkonttorista muualla sijaitsevan serverin
tuotetietokantaan.

Ei sen serverin ole pakkon sijaita fyysisesti pääkonttorissa, vaikka
pääkonttori olisi yksiselitteisessä vastuussa tuotetietokannan
päivityksestä. Kannattaa ihan tarkkaan katsoa pääkonttorin
tuotepäivitysten ja koko firman (+mahdollisten asiakaiden) kyselyjen
suhdetta ja sen mukaan päättää, missä se serveri fyysisesti sijaitsee.

[Asko Ikävalko]

Juha L. wrote:
> Kahdelle uusissa tiloissa toimiville sivukonttoreille saa vaikka
> valokuidun tilattua. Mutta pääkonttori ja sen serveri ovat melkein
> maalla. Liki 5 km päässä puhelinkeskuksesta, eikä linjanopeuttaa sinne
> pystytä ainakaan ADSL:llä teknisesti nostamaan.

Kannattanee vielä kysyä DNA:lta, voisiko yhteyden toteuttaa jollain
muulla xDSL tekniikalla. Esimerkiksi 4/4 Mbps yritysliittymä voisi jo
olla paljon parempi ratkaisu, jos sellaisen vaan tuonne saa.

> Serverikoneet ovat Windows-koneita, ja ADSL-purkit jotakin mahdollisesti
> Telewellin tai TP-linkin tms. peruspurkkeja.

Peruspurkistakin pitäisi löytyä sellainen loki, jossa se kertoo että
millaisen yhteyden se on kätellyt. Mulla oli aikoinaan DSL-yhteyden
kanssa ongelma, että se ei saanut käteltyä läheskään sitä nopeutta minkä
olin tilannut. Vika korjaantui puolen vuoden valittamisen jälkeen, kun
vihdoin asentaja vaivautui paikalle ja kytki jossain ristijakamossa
yhteyteni toiselle kaapeliparille. Kokemukseni mukaan DSL-linja kyllä
yleensä jaksaa sen kuljettaa, mitä on kättelyssä luvannut kuljettavansa.

> Mikähän järjestely näissä toimisi? Onko seuranta helpompaa
> Serveripäästä, vai kannattaisiko seurata kuitenkin Työasemien päästä?

Kyllä se sieltä serverin päästä pitäisi yrittää diagnosoida. Itse
laittaisin ainakin ihan aluksi sinne palvelimelle jatkuvan pingin
pyörimään ja seuraisin että nouseeko pingit jossain tietyssä tilanteessa
yli 100 ms, vai pysyykö kokoajan iloisesti alle 30 ms. Sen voi jättää
yöksikin pyörimään ja tutkia tuleeko yöllä paljonkin parempia
vasteaikoja kuin virka-aikana, jolloin linjalla on enemmän kuormaa.
Pingin kohteeksi joku mahdollisimman järeä rauta, esim. www.funet.fi tai
ficix.fi

Voisin myös mittailla yhteysnopeutta siirtelemällä jotain 100 Mt
tiedostopakettia verkon yli sinne haarakonttorille ja mittaamalla
sekuntikellolla aikaa.

Jos nämä molemmat testit menee läpi kirkkain tuloksin, alkaisin etsiä
vikaa palvelimella pyörivistä sovellusohjelmista tai pääkonttorin
työasemista.

-Asko

[upsid...@downunder.com]

On Sun, 11 Aug 2013 21:10:22 +0300, Asko Ikävalko
<ikaval...@poista.pp.inet.fi.invalid> wrote:

>
>> Mikähän järjestely näissä toimisi? Onko seuranta helpompaa
>> Serveripäästä, vai kannattaisiko seurata kuitenkin Työasemien päästä?
>
>Kyllä se sieltä serverin päästä pitäisi yrittää diagnosoida. Itse
>laittaisin ainakin ihan aluksi sinne palvelimelle jatkuvan pingin
>pyörimään ja seuraisin että nouseeko pingit jossain tietyssä tilanteessa
>yli 100 ms, vai pysyykö kokoajan iloisesti alle 30 ms. Sen voi jättää
>yöksikin pyörimään ja tutkia tuleeko yöllä paljonkin parempia
>vasteaikoja kuin virka-aikana, jolloin linjalla on enemmän kuormaa.
>Pingin kohteeksi joku mahdollisimman järeä rauta, esim. www.funet.fi tai
>ficix.fi

Vaikka ping/tracert komennoilla voidaan selvittää alle sekunnin
aikaskaalan ongelmia, pahoin pelkään, ettei sillä juuri voi 15
sekunnin ongelmia selvitellä. Joko se putki on jossain paikassa
(operaattorin toimesta) vedetty hyvin kapeaksi tai sitten uplinkin
sähköinen laatu on todella heikko (esim. ylikuulumisen takia), jolloin
saman paketin peräkkäisillä uudelleenlähetyksillä linkin kapasiteetti
putoaa todella rajusti.

Jos hetkeksi (esim. ruokatunnin ajaksi) oma liikenne voidaan pysäyttää
ja tehdä yksi ainokainen kysely ja katsoa kauanko se kestää. Jos
kyselyn vaste on huonompi kuin yöaikaan, joko operaattorin
runkoverkkokapasiteetti on ala-arvoinen tai sitten puhelinkaapelin
ylikuuluminen pudottaa kapasiteettia rajusti.

Mutta kuten aikaisemmassa viestissä totesin, minä en laittaisi
servereitä kyseenalaisten puhelinkaapeleiden (ADSL) perään.

[Ari Saastamoinen]

"Juha L." <not-w...@none.fi> writes:

> Mikähän järjestely näissä toimisi? Onko seuranta helpompaa
> Serveripäästä, vai kannattaisiko seurata kuitenkin Työasemien päästä?
> Suht kevyellä ohjelmallisella overheadilla saisi toimia, ettei se
> seurantaohjelma ala sitten jo haukata merkittäviä tehoja
> Windowsistakin. Tai ettei se vie omaa osaansa ADSL-linjan
> kapasiteettia.

Suurinpiirtein kaikki xDSL-reitittimet osaavat pitää tilastoa
siirretystä datamäärästä ja ne osaavat kertoa myös nopeuden, jonka
vastapään kanssa ovat saaneet käteltyä. Toi linjanopeus ei yleensä
käytön ainakan vaihdu, ja pirtät jonkun softan (esim., MRTG on paljon
käytetty) tota siirretyn datamäärän laskuria vaikkapa viiden minuutin
välein niin saat hienoja graafejakin.

Jos tuon linjan yli ei muuta käytetä kuin jotain pieniä
tietokantakyselyitä, niin epäilen, että siihen pitäisi riittää
megainen uploadikin ihan hyvin. (Miksi tuo tietokantapalvelin ei ole
siellä jossain paremmalla bitillä varustetussa sivukonttorissa?) Ja
käy mielessä myös sekin, että onko siinä sun DSL-purkissasi maailmalta
avoin DNS-ripiitteri (aina monessa on), ja jos pahat pojat maailmalta
ovat keksineen sen, niin todennäköisesti tuota boksia käytetään
dns-amplifierina DDoS-hyökkäyksissä ja se siten samalla tukkii sen
teidän omankin piuhan. (Tuo DSL-boksien amplifierikäyttö on
yllättävän yleistä)

--
Arzka oh3mqu+...@hyper.fi - En halua follareita mailina
1. Valitse sopiva paikka, ei ihmisten tai rakennusten lahella, jossa
paukku voi aiheuttaa hairiota. - Iso-Kiinalaisen kayttoohje

[PW]

12.8.2013 0:42, Ari Saastamoinen kirjoitti:

> Suurinpiirtein kaikki xDSL-reitittimet osaavat pitää tilastoa
> siirretystä datamäärästä ja ne osaavat kertoa myös nopeuden, jonka
> vastapään kanssa ovat saaneet käteltyä. Toi linjanopeus ei yleensä
> käytön ainakan vaihdu, ja pirtät jonkun softan (esim., MRTG on paljon
> käytetty) tota siirretyn datamäärän laskuria vaikkapa viiden minuutin
> välein niin saat hienoja graafejakin.

Mitenkähän tuon kulloisenkin vastapään kanssa kätellyn nopeuden saa
selville xDSL reitittimestä?

Jos linjanopeudella et tarkoita sitä, mitä sanot, niin tuo pitää paikkansa.
Modeemi kättelee jokaisen yhteyden kanssa nopeuden erikseen, joten tuo
nopeus voi vaihdella suurestikin.
Päätelaitteen ja ADSL DSLAM:n välinen kytkeytymisnopeus on yleensä
hyvinkin kiinteä.

DNA/Welhon verkossa näyttää nopeustestin tulos vaihtelevan melko paljon
eri testikerroilla.

[Ari Saastamoinen]

PW <_@_._> writes:

> Mitenkähän tuon kulloisenkin vastapään kanssa kätellyn nopeuden saa
> selville xDSL reitittimestä?

Toi riippuu ihan käytetystä reititinmallista. Osa kertoo sen
webbikäyttöliittymässään, ja joissain tarttee kirjoittaa komentoja
jne.

> Jos linjanopeudella et tarkoita sitä, mitä sanot, niin tuo pitää paikkansa.
> Modeemi kättelee jokaisen yhteyden kanssa nopeuden erikseen, joten tuo
> nopeus voi vaihdella suurestikin.

Minkä hiton yhteyden alussa? ADSL-härpäkehän pidetään seinässä 24/7
ja näin ollen siinä on vain yksi yhteys (kunnes tulee sähkökatko tai
joku muu häiriö)

> Päätelaitteen ja ADSL DSLAM:n välinen kytkeytymisnopeus on yleensä
> hyvinkin kiinteä.

Noi härpäkkeet käyttävät kotiboksin ja DSLAMin välissä joitain ihan
poikkeuksia lukuunottamatta sitä käteltyä linjanopeutta. Ja noissa
kahdessa mainitsemassasi nopeudessa ei yleensä ole mitään eroa.

Mikäli nopeutta on jotenkin rajoitettu, niin sitten nuo pyrkivät
kättelemään sen valitun nopeuden, mutta mikäli profiilina on "käytä
parasta", niin sitten tuo vaihtelee eri yhteyskertojen välillä enempi.

> DNA/Welhon verkossa näyttää nopeustestin tulos vaihtelevan melko
> paljon eri testikerroilla.

No se riippuu aika paljon siitäkin, että mitä käytät nopeustestisi
vastapäänä. Olen monesti törmännyt siihenkin tilanteeseen, että se
vastapää ei kykene puskemaan dataa riittävän nopeasti, ja se sitten
näkyy testituloksessa.

[PW]

12.8.2013 8:27, Ari Saastamoinen kirjoitti:

>> Jos linjanopeudella et tarkoita sitä, mitä sanot, niin tuo pitää paikkansa.
>> Modeemi kättelee jokaisen yhteyden kanssa nopeuden erikseen, joten tuo
>> nopeus voi vaihdella suurestikin.
>
> Minkä hiton yhteyden alussa? ADSL-härpäkehän pidetään seinässä 24/7
> ja näin ollen siinä on vain yksi yhteys (kunnes tulee sähkökatko tai
> joku muu häiriö)

Et näköjään ymmärtänyt asiaa :-(
DSLM:n ja käyttöpaikan välinen nopeus on ihan eri asia, kun se nopeus,
joka saadaan siihen osoitteeseen, mihin ollaan kulloinkin kytkeydytty.
DSLAM:n ja käyttöpaikan välinen kytkeytymisnopeus ei juuri mitään kerro
kunkin käyttötilanteen nopeudesta.

>> DNA/Welhon verkossa näyttää nopeustestin tulos vaihtelevan melko
>> paljon eri testikerroilla.
>
> No se riippuu aika paljon siitäkin, että mitä käytät nopeustestisi
> vastapäänä. Olen monesti törmännyt siihenkin tilanteeseen, että se
> vastapää ei kykene puskemaan dataa riittävän nopeasti, ja se sitten
> näkyy testituloksessa.
>

DNA/Welhon omassa nopeustestissä ei nopeustestin vastapäätä voi valita.
Peräkkäisten nopeustestien arvot poikkeavat usein paljon toisistaan
(vastaanottonopeuden suhteen). Tuossa aplikaatiossa lienee jotain vikaa,
kun se toimii eri kerroilla eri tavalla (lähetysnopeus joskus 0,01 Mbit/s).

[upsid...@downunder.com]

On Mon, 12 Aug 2013 09:47:17 +0300, PW <_@_._> wrote:

>12.8.2013 8:27, Ari Saastamoinen kirjoitti:
>
>>> Jos linjanopeudella et tarkoita sitä, mitä sanot, niin tuo pitää paikkansa.
>>> Modeemi kättelee jokaisen yhteyden kanssa nopeuden erikseen, joten tuo
>>> nopeus voi vaihdella suurestikin.
>>
>> Minkä hiton yhteyden alussa? ADSL-härpäkehän pidetään seinässä 24/7
>> ja näin ollen siinä on vain yksi yhteys (kunnes tulee sähkökatko tai
>> joku muu häiriö)
>
>Et näköjään ymmärtänyt asiaa :-(
>DSLM:n ja käyttöpaikan välinen nopeus on ihan eri asia, kun se nopeus,
>joka saadaan siihen osoitteeseen, mihin ollaan kulloinkin kytkeydytty.
>DSLAM:n ja käyttöpaikan välinen kytkeytymisnopeus ei juuri mitään kerro
>kunkin käyttötilanteen nopeudesta.

Miten tarkkaan ottaen tuo upload nopeuden rajoitus on tehty ?

Hylätäänkö yksinkertaisesti pakettaja tietyn määrän jälkeen ja
toivotaan, että TCP/IP hoitaa uudelleenlähetyksenä poispudotetut
paketit ? Tässähän purevat sitten TCP/IP timeoutit ja pahimmassa
tapauksessa TCP/IP vielä hidastaa liikennettä, kuvitellen, että ruuhka
on entistä pahempi. Tämä voisi selittää monien sekuntien
loppukäyttäjäviiveet.

Vai käytetäänkö jotain kehittyneempää menetelmää, kuten TCP headerin
manipulointia, kuten satelliitti-internetissä ?

[Juhai L.]

upsid...@downunder.com wrote:
>
> Tämä on helposti todettavissa rinnakkaisella
> puhelinyhteydellä, jossa kyselyn lähettävä henkilö kertoo kyselyn
> lähetyksestä ja seurataan serverin samanaikaisesti lokista, koska
> kyselyä alettiin ihan oikeasti käsittelemmään.

Vain käyttäjien sisään- ja uloskirjautumisen ajat näkyvät. Yksittäisten
SQL-kyselyjen aikaleimoja ei pääse seurailemaan logeista.

> Varmimmin tuota voisi tutkia tcpdump kaltaisilla työkaluilla, jossa
> voisi katsoa kuinka isoja ikkunakokoja clientti julkaisee, eli kuinka
> pienissä paloissa serveri joutuu lähettämään vastauksensa.
> Valitettavasti näiden lokien tulkinta on varsin hankalaa.

Jotain tämän tyypin ohjelmaa tosiaan etsiskelin. Joku sellainen josta
end-userikin saisi tarjotuista raporteista jotakin tolkkua ulos.

> Jos kerran tämä on tilanne, miksei serveri sijaitse jommassa kummassa
> sivukonttorissa (tai kalleimmassa tapauksessa webbihotellissa) ?

Liittyy sivukonttorien henkilökunnan kädettömyyteen. Kaikenlaiset
it-taidot ovat nollan paikkeilla, ja kiinnostus sen puolen asioihin
menee jo asteikon negatiiviselle puolelle.

Lisävaivana on vielä nettikauppakin, josta tulevia tilauksia imaistaan
sisään järjestelmään. Pikku pakko pitää tätä serveriäkin ns.
pääkonttorilla sen vuoksi. Mutta on tuotakin asiaa kyllä hätäratkaisuna
harkittu harkittu.

> Hidaskin modeemi/GPRS yhteys varmasti riittää yksitäisten tietojen
> päivittämisen pääkonttorista muualla sijaitsevan serverin
> tuotetietokantaan.

Kyseinen ohjelma toimii mainiosti esim. sellaisen ADSL-linjan ylitse
jossa serveripää tarjoaa esim. 1.4 Mbit upload-nopeutta. Tuo pystyttiin
tuollakin käytännössä testaamaan, laittamalla serveri tilapäisesti yhden
työntekijän kotiin ADSL:n taakse.

[PW]

12.8.2013 10:04, upsid...@downunder.com kirjoitti:

> Miten tarkkaan ottaen tuo upload nopeuden rajoitus on tehty ?

Toteutustapaa en tiedä!
Se on kuitenkin maksimi ja se jakautuu kaikkien yhtäaikaisten käyttäjien
kesken.
Lopputulokseen vaikuttanee yhteydenmuodostustapa sivukonttorista ja
pääkonttorin nettikäytöstä aiheutuva ruuhkaisuus - esim. aktiiviset
nyyssien- ja naamakirjan käyttäjät.

[Juhai L.]

Asko Ikävalko wrote:
>
> Esimerkiksi 4/4 Mbps yritysliittymä voisi jo
> olla paljon parempi ratkaisu, jos sellaisen vaan tuonne saa.

Alkuvuodesta tuollaista 2/2 megan linjaa tarjosivat, suurempia nopeuksia
ei välttämättä saa, pitkän loppulinjan vuoksi. Linjan kk-hinta oli
luokkaa 250€/kk, joka tuntui ADSL:n hintoihin tottuneelta aika kovalta.

Lisäksi kun ei ole 100% varmuutta että korjaantuuko vika edes tuolla.
Jos se lopulta ei olekaan syynä että ADSL-linjan 1 Mbit
upload-kapasiteetti toottaisi koko ajan tukkeessa ja täysillä, ja että
sen kaista ei riitä. Vika voi lopulta olla joku yksinkertainen asetus-
tai kytkentäongelma.

> Peruspurkistakin pitäisi löytyä sellainen loki, jossa se kertoo että
> millaisen yhteyden se on kätellyt. Mulla oli aikoinaan DSL-yhteyden
> kanssa ongelma, että se ei saanut käteltyä läheskään sitä nopeutta minkä
> olin tilannut. Vika korjaantui puolen vuoden valittamisen jälkeen, kun
> vihdoin asentaja vaivautui paikalle ja kytki jossain ristijakamossa
> yhteyteni toiselle kaapeliparille.

Jotakin tuollaista itsekin epäilen. Pitäisi näköjään käyttäjän itsensä
pystyä todistamaan DNA:lle asia, muuten eivät ala vaihtelemaan. Siksi
jurui jonkinlaista kättä pidempää apua ettiskelen.

> Pingin kohteeksi joku mahdollisimman järeä rauta, esim. www.funet.fi tai
> ficix.fi

Minkäs niminen Windows-pingisofta tässä olisi suositeltava? Helpohko
mutta luotettavahko.

> Voisin myös mittailla yhteysnopeutta siirtelemällä jotain 100 Mt
> tiedostopakettia verkon yli sinne haarakonttorille ja mittaamalla
> sekuntikellolla aikaa.

Tätä on kokeiltu, että laitetaan hidastelevan sovellusohjelman rinnalle
tiedostonsiirto päälle.

Vaikka tiedostonsiirto on päällä, sovellusohjelman nopeudessa ei tunnu
tulevan lisähidastumista. Tästä ei ole muuta kuin mutu-tuntumaa,
mittausohjelmilla ei ole rinnalla mittailtu että mikä on se todellinen
vaikutus.

En tunne TCP-sanastoa, mutta voiko kyse olla erilaisista protokollista?
Tiedostonsiirto menee jollakin FTP-siirrolla, yhtenä blokkina, ja
siirtonopeus näyttää hyvältä. Mutta kyselytyyppinen ohjelmisto käyttää
jotakin muuta protokollaa, uudelleenkytkeytyilee useasti ja pilkkoo ja
paketoi datansa jotenkin eri tavalla.

[Juhai L.]

upsid...@downunder.com wrote:
>
> Mutta kuten aikaisemmassa viestissä totesin, minä en laittaisi
> servereitä kyseenalaisten puhelinkaapeleiden (ADSL) perään.

Noita on softan toimittajan mukaan samanlaisia käyttöpaikkoja
ADSL-linjoilla kymmenittäin eri puolilla maata.

Tuo sukulainen on pystynyt itsekin todentamaan että 1.4 Mbit
upload-nopeutta tarjoavan kotilinjan takana heidän serverinsä (tosin
vanhalla varakoneella, eri PC-serverikoneella testaten) ja
tietokantansa, noilta sivukonttoreilta käsin testattuna, se toimii
täysin tyydyttävällä nopeudella.

Jotenkin vaivan syyhyn ei nyt tunnu saavan kiinni, että mikä ahistaa.

[Juhai L.]

Ari Saastamoinen wrote:
>
> Suurinpiirtein kaikki xDSL-reitittimet osaavat pitää tilastoa
> siirretystä datamäärästä ja ne osaavat kertoa myös nopeuden, jonka
> vastapään kanssa ovat saaneet käteltyä.

Esimerkiksi oma Telewellin EA-501 purkki tarjoaa vain Järjestelmäloki ja
Plomuurioloki listaukset. Järjestelmäloki näyttää tältä:

Jan 1 00:00:04 syslog: after tcp_large_port_timeout=120
Jan 1 00:00:04 syslog: eth0: starting interface.
Jan 1 00:00:05 syslog: device eth0 entered promiscuous mode
Jan 1 00:00:05 syslog: br0: port 1(eth0) entering learning state
Jan 1 00:00:05 syslog: br0: port 1(eth0) entering forwarding state
Jan 1 00:00:08 syslog: Dyingasp ON!^M
Jan 1 00:00:09 syslog: ANNEXAIJLM^M
Jan 1 00:00:09 syslog: Open Loop Detect Enable ^M
Jan 1 00:00:09 syslog: Valid ave snrm cnt = 1^M
Jan 1 00:00:09 syslog: EC OFF!!^M
Jan 1 00:00:09 syslog: EC ON!!^M

Tuosta ei kovin isoa iloa ole. Minulla olisi tytinä että ei normaalit
halvat perus ADSL-purkit tuollaista tilastoa tarjoa muutenkaan.
Kalliimmat mallit sitten varmaan tarjonnevat.

> käytön ainakan vaihdu, ja pirtät jonkun softan (esim., MRTG on paljon
> käytetty) tota siirretyn datamäärän laskuria vaikkapa viiden minuutin
> välein niin saat hienoja graafejakin.

Pitäis ehkä ensin löytää osaavampi purkki, tai sitten se jokin kätevä
apuohjelma, jota alun perinkin etsiskelin. Niiden datasta voisi sitten
käyriäkin jo piirrellä.

> Jos tuon linjan yli ei muuta käytetä kuin jotain pieniä
> tietokantakyselyitä, niin epäilen, että siihen pitäisi riittää
> megainen uploadikin ihan hyvin.

Aivan alkuperäinen oma ounastelu liittyy juuri tähän. Että jos 1.4 Mbit
uploadilla toisaalle toimii hyvillä vasteajoilla, niin ei sen silloin
0.9 Mbitillä pitäisi kymmenien sekuntien mateluun laskea. Joku asia
ahistaa, mutta mikä.

> jos pahat pojat maailmalta
> ovat keksineen sen, niin todennäköisesti tuota boksia käytetään
> dns-amplifierina DDoS-hyökkäyksissä ja se siten samalla tukkii sen
> teidän omankin piuhan. (Tuo DSL-boksien amplifierikäyttö on
> yllättävän yleistä)

Kyseinen purkki on täysin DNA:n hemmojen konffaama, itse olen ollut vain
Teamviewer-yhteydessä serveriin. Luulisi DNA:n perushommat osaavan,
mutta eihän mikään ole ikinä ihan varmaa.
Mikähän olisi sopiva keino tai ohjelmisto testata ettei tällaista purkin
läpiajon käyttöä ole päällä?

[PW]

12.8.2013 12:27, Juhai L. kirjoitti:

> Alkuvuodesta tuollaista 2/2 megan linjaa tarjosivat, suurempia nopeuksia
> ei välttämättä saa, pitkän loppulinjan vuoksi. Linjan kk-hinta oli
> luokkaa 250€/kk, joka tuntui ADSL:n hintoihin tottuneelta aika kovalta.

Olisi kannattanut ottaa!

> Lisäksi kun ei ole 100% varmuutta että korjaantuuko vika edes tuolla.

Olisi varmasti korjannut tilanteen.

On hyvä muistaa, että ADSL on ongelmayhteysmuoto, etenkin pitkillä
tilaajajohdoilla.

8/1 Mbit/s yhteyden vastaanottonopeus laskee voimakkaasti, kun
tilaajajohto pitenee.
Pisimmillä tilaajajohdoilla vastaanottonopeus ei juuri 2 Mbit/s
suuremmaksi nouse.
Pitkillä tilaajajohdoilla lähetysnopeus on ongelmallinen.
Puhelinkaapeleihin mahtuu varsin rajallinen määrä ADSL-yhteyksiä, kun
tilaajakaapeleissa on pareilla vain 6 kpl eri nousuja. ADSL-yhteydet
pitäisi sijoittaa eri nousuille niin, että nelikierteet tai parit eivät
olisi kaapelissa vierekkäin ja ovat eri nousuilla.
Tätä vaikeuttaa nykysysteemi, kun ADSL-yhteys halutaan puhelimen kanssa
samalle parille (pareja ei vaihdeta), jolloin tulee helposti tilanteita,
että ADSL-yhteydet häiritsevät toisiaan.
Ja sitten vielä tämä lähetysnopeusongelma. Kun saman tilaajakaapelin eri
kohdissa on ADSL-liittymiä, niin kauimpana olevan liittymän signaali
vaimenee koko ajan, kun se kaapelissa kulkee. Lähempää kaapeliin tuleva
signaali on voimakkaampi, jolloin se häiritsee tätä jo vaimentunutta
signaalia - ja vielä sitä enemmän, mitä epäideaalisemmin ADSL-yhteydet
on kaapeliin sijoittuneet.

[Ari Saastamoinen]

"Juhai L." <not-w...@none.fi> writes:

> Esimerkiksi oma Telewellin EA-501 purkki tarjoaa vain Järjestelmäloki
> ja Plomuurioloki listaukset. Järjestelmäloki näyttää tältä:

> ...

> Tuosta ei kovin isoa iloa ole. Minulla olisi tytinä että ei normaalit
> halvat perus ADSL-purkit tuollaista tilastoa tarjoa
> muutenkaan. Kalliimmat mallit sitten varmaan tarjonnevat.

Tässä pikaisesti googletin Ea-501:sen manuaalia, niin löysin urlin
https://www.google.fi/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCsQFjAA&url=http%3A%2F%2Fsolitudo.net%2Fhardware%2Fmanuals%2FTW-EA501_versio1_ohjekirja.pdf&ei=uc0IUoDHI8364QSB4YH4Bw&usg=AFQjCNEUhguDDafe5AsQ1qbbM5oPUKSziw&bvm=bv.50500085,d.bGE&cad=rja (Sairaan kaunis :)

Ja tuossa sivulla 52 väitetään, että toi osais jotain
siirtostatistiikkaakin kertoa. Tosin ilmeisesti ainoastaan packets /
second tasolla eikä näyttäisi olevan bytes / secondia. Mutta kyllä
tuostakin jotain saa irti.

> Kyseinen purkki on täysin DNA:n hemmojen konffaama, itse olen ollut
> vain Teamviewer-yhteydessä serveriin. Luulisi DNA:n perushommat
> osaavan, mutta eihän mikään ole ikinä ihan varmaa.

Joissain bokseissa tuota ei saa lainkaan konffattua pois päältä vaikka
operaattori osaisikin - operaattori voi vain yrittää usuttaa boksin
valmistajaa julkaisemaan paremman firmwaren. En nyt muista oliko toi
telewelli tuollainen, josta sitä ei saa estettyä.

> Mikähän olisi sopiva keino tai ohjelmisto testata ettei tällaista
> purkin läpiajon käyttöä ole päällä?

Eipä tuohon juuri muuta taida olla kuin, että teet tilastoa tuosta
siirretystä pakettimäärästä, ja jos piikittää, niin tiedät, että JOKU
siirtää dataa, ja jos se ei ole kukaan teiltä, niin sitten se on joku
ulkopuolinen.

[PW]

12.8.2013 12:27, Juhai L. kirjoitti:

> Pitäisi näköjään käyttäjän itsensä
> pystyä todistamaan DNA:lle asia, muuten eivät ala vaihtelemaan. Siksi
> jurui jonkinlaista kättä pidempää apua ettiskelen.

DNA:n yhteysnopeudet voi tarkistaa osoitteessa:
http://www2.dna.fi/nopeus/nopeusmittari
ja muut osoitteessa http://www.speedtest.net/

Niisä on sekä vastaanotto- että lähetysnopeus.

[Juhai L.]

Ari Saastamoinen wrote:
>
> Ja tuossa sivulla 52 väitetään, että toi osais jotain
> siirtostatistiikkaakin kertoa. Tosin ilmeisesti ainoastaan packets /
> second tasolla eikä näyttäisi olevan bytes / secondia. Mutta kyllä
> tuostakin jotain saa irti.

Tämän Easytel Oy:n ADSL 2+ mallina markkinoitavan uudemman EA-501 mallin
käsikirja on täällä.
https://www.telewell.fi/files/ohjekirjat/TW-EA501v3b_ohjekirja.pdf

User interface selaimella katseltuna on nyt kokonaan suomennettu.

Mitään linjanopeuksiin liittyviä lukemia ei löydy sen paremmin
käsikirjasta hakemalla kuin käyttöliittymästäkään. Kaikki piilotettu pois.

> Joissain bokseissa tuota ei saa lainkaan konffattua pois päältä vaikka
> operaattori osaisikin - operaattori voi vain yrittää usuttaa boksin
> valmistajaa julkaisemaan paremman firmwaren. En nyt muista oliko toi
> telewelli tuollainen, josta sitä ei saa estettyä.

Tuo EA-501 purki löytyy vain oamsta käytöstäni. En edes tarkalleen tiedä
minkä merkkinen purkki tuolla sukulaisella on. Pitänee ottaa selvää ja
katsoa olisiko siellä valikoissa jotakin ADSL-portin siirron
mittauslukemia saatavilla.

> Eipä tuohon juuri muuta taida olla kuin, että teet tilastoa tuosta
> siirretystä pakettimäärästä, ja jos piikittää, niin tiedät, että JOKU
> siirtää dataa, ja jos se ei ole kukaan teiltä, niin sitten se on joku
> ulkopuolinen.

Tuntuisi vähän historic -hommalta jos pitäisi silmin katsoen seurailla
ja käsin kirjoitella noita tietoja eri vuorokauden ajoilta ylös.

Alkuperäisenä toiveena oli löytää joku softa jonka voisi jättää
vuorokaudeksi päälle ja se suoraan keräisi tuota dataa.

Ainakaan Telewellin mainittu EA-purkki ei sellaista liittymärajapintaa
tarjoa. Ehkä joku hiukan monipuolisempi ADSL-purkki voisi jotakin
tarjotakin.

[PW]

12.8.2013 18:31, Juhai L. kirjoitti:

> Tämän Easytel Oy:n ADSL 2+ mallina markkinoitavan uudemman EA-501 mallin
> käsikirja on täällä.
> https://www.telewell.fi/files/ohjekirjat/TW-EA501v3b_ohjekirja.pdf

> Mitään linjanopeuksiin liittyviä lukemia ei löydy sen paremmin
> käsikirjasta hakemalla kuin käyttöliittymästäkään. Kaikki piilotettu pois.

Ohje sivulla 26 kohta 4.4.1.1 "ADSL-verkon tila" kertoo lähetyksen- ja
vastaanoton kytkeytymisnopeudet DSLAM:n.

[Asko Ikävalko]

Ari Saastamoinen wrote:
> Jos tuon linjan yli ei muuta käytetä kuin jotain pieniä
> tietokantakyselyitä, niin epäilen, että siihen pitäisi riittää
> megainen uploadikin ihan hyvin.

Niin, JOS. Juha ei vielä kertonut, että montako muuta palvelinta ja
työasemaa on sen samaisen nettiletkun äärellä.

> (Miksi tuo tietokantapalvelin ei ole
> siellä jossain paremmalla bitillä varustetussa sivukonttorissa?)

Kenties köyhällä pikkufirmalla ei ole varaa kuin yhteen palvelimeen.
Luultavasti se sama palvelin toimii pääkonttorin levypalvelimena ja ehkä
myös tulostuspalvelimena ja DC:nä.

> onko siinä sun DSL-purkissasi maailmalta
> avoin DNS-ripiitteri (aina monessa on)

Eikös aika monessa purkissa ole palomuuri blokkaamassa kaiken
sisääntulevan liikenteen. Kyllä kai tuo koskee myös DNS-liikennettä?

-Asko

[Ari Saastamoinen]

"Juhai L." <not-w...@none.fi> writes:

> Tämän Easytel Oy:n ADSL 2+ mallina markkinoitavan uudemman EA-501
> mallin käsikirja on
> täällä. https://www.telewell.fi/files/ohjekirjat/TW-EA501v3b_ohjekirja.pdf

Tossa manuaalissa kerrotaan myös SNMP:stä, joten ilmeisesti toi
härpäke osaa SNMP:lläkin tarjoilla noita statseja. Ja MRTG ainakin
osaa SNMP:llä kysellä dataa.

[Ari Saastamoinen]

Asko Ikävalko <ikaval...@poista.pp.inet.fi.invalid> writes:

> Eikös aika monessa purkissa ole palomuuri blokkaamassa kaiken
> sisääntulevan liikenteen. Kyllä kai tuo koskee myös DNS-liikennettä?

Tua operaattoreiden välisessä keskustelussa tuosta juuri puhuttiin
muutama viikko sitten, ja siellä totesivat, että tuota EI VOI käytössä
olevilla firmisversioilla estää joissain (yleisissä) purkeissa.

[Juhai L.]

Ari Saastamoinen wrote:
>
> Tossa manuaalissa kerrotaan my�s SNMP:st�, joten ilmeisesti toi
> h�rp�ke osaa SNMP:ll�kin tarjoilla noita statseja. Ja MRTG ainakin
> osaa SNMP:ll� kysell� dataa.
>

Mink�h�n n�k�ist� ha tasoista dataa noista purkeista k�yt�nn�ss� pit�isi
SNMP:n avulla saada ulos?

Kokeilin asentaa tuota Perlin pohjalle tehty� MRTG:t�kin. Mutta v�s�hdin
lukemaan manuaalia ja Linux-v�elle kirjoitettujen komentokehoitteen
erilaisia kutsuja.

Sen sijaan aloin kokeilla t�llaista enemm�n Windowsin oloista ilmaista
PowerSNMP ty�kalua http://www.dart.com/snmp-net-library-api.aspx .

Local koneessani olevalta Zyxelin Zywall purkilta sain kyselty�
t�llaisia arvoja ulos:

Variable (Oid) ........... Value
------------------------------------
sysDescr (1.3.6.1.2.1.1.1) ..... ZyWALL 2
tcpInSegs (1.3.6.1.2.1.6.10) ..... 3416
tcpOutSegs (1.3.6.1.2.1.6.11) ..... 4135
tcpActiveOpens (1.3.6.1.2.1.6.5) ..... 13
sysUpTime (1.3.6.1.2.1.1.3) ..... 803230500
sysServices (1.3.6.1.2.1.1.7) ..... 14
tcpRetransSegs (1.3.6.1.2.1.6.12) ..... 38
tcpMaxConn (1.3.6.1.2.1.6.4) ..... -1
tcpPassiveOpens (1.3.6.1.2.1.6.6) ..... 74
tcpAttemptFails (1.3.6.1.2.1.6.7) ..... 0
tcpEstabResets (1.3.6.1.2.1.6.8) ..... 8
tcpCurrEstab (1.3.6.1.2.1.6.9) ..... 0
tcpInErrs (1.3.6.1.2.1.6.14) ..... 0
tcpOutRsts (1.3.6.1.2.1.6.15) ..... 0
tcpRtoAlgorithm (1.3.6.1.2.1.6.1) ..... 4
tcpRtoMin (1.3.6.1.2.1.6.2) ..... 0

Melkein kaikkia muita PowerSNMP ohjelman valikossa olleita arvoja
kyselless� tulee "NoSuchName" virhevaste. Aika lailla samanlaisia
tuloksia tuli my�s Telewellin EA-purkilta kyselem�ll�, ei selke��
todellista linjanopeutta saa kyselty� ulos.

Tuosta yll� olevasta listasta tunnistan kaksi arvoa joilla voisi olla
jotakin tekemist� purkin l�p�isseen datam��r�n kanssa, "tcpInSegs" ja
"tcpOutSegs".

Noita arvoja voi ko. ohjelmalla kysell� vaikka 5 sekunnin v�lein. Mutta
eiv�t nuo arvot ruudulla reaaliajassa p�ivity vaikka taustalla imuttaa
jotakin isoa tiedostoa alas. Kyll� ne numerot kuitenkin lopulta
p�ivittyv�t, arviolta 20..30 minuutin v�lein.

Onkohan t�m� taso se siirretyn datam��r�n taso joka SNMP-protokollan
avulla ylip��t��n on ADSL-tyyppisilt� purkeilta saatavilla? Vain hyvin
karkealla tasolla olevaa, kumulatiivista dataa.

Ideana oli ett� tehd� sill� hidastelevalla sovellusohjelmalla
SQL-kyselyj�, ja katsoa paljonko ADSL-linjan l�pi silloin kulkee dataa,
vaikka 1 minuutin aikana.
Mutta eip� t�m� SNMP:n kautta tarjolla oleva karkea data sellaisia
asioita kerro lainkaan.