Bratislava inline

[Suik]

V "preferences" subore su zaujimave riadky, ktore este na 2.4.x androide (asi) fungovali, od 3.x nie, okrem guriho spesl twiikov

Code: Select all

Traffic Detection.Feature enabled: yes
...
Traffic Detection. Number of seconds to ask: 30
...
Traffic Detection.Speed: 15

[guri211]

Priatelia, nemam teraz cas, ale urcite sa k vasim klebetam vyjadrim

[guri211]

Ahojte priatelia,

Takze aby bolo jasno:

1.) INTL waze klient infrastruktura je v skratke tvorena dvomi oblacikmi - jeden z nich je tzv. "real-time server", ktory bezi na AWS. Ma na starosti prihlasovanie do klienta, zobrazovanie wazerov, zobrazovanie dat (zapchy a eventy), a preberanie vsetkych informacii od klientov. Druhy oblak je tzv. "routing server", ktory ma na starosti planovanie cesty najlepsou moznou trasou vzhladom na historicke a realtime data. Samozrejme je tam aj kopec dalsich ucelovych sucasti (ako napr. server ktory distribuuje map tiles pre klientov aj pre WME), ale to teraz nie je podstatne. [Zistene odchytavanim dat, studovanim zdrojaku, ciastocne z vyjadreni od waze]

2.) Cela infrastruktura bojuje s kapacitnymi problemami. Prakticky jedina cast ktora nimi netrpi je real-time server beziaci na AWS. Kvoli tymto problemom musia ajtaci z waze robit vela optimalizacnych opatreni. Preto im tak dlho trva implementacia novych funkcii - snazia sa aby zatial spolahlivo bezali aspon tie stare, co casto vedie az k extremnym opatreniam. Problem je, ze Waze o tomto nekomunikuje, dokonca ani s top wazermi. Vsetci dufame, ze coskoro sa to zlepsi. [Vlastne zistenia + zahmlene oficialne info]

A teraz podme k podstatnemu:

3.) Waze klient po zapnuti caka, kym dosiahnete urcitu rychlost (30? 40? km/h - neviem), cim sa potvrdi ze uz idete v aute. Az po tom reportuje real-time serveru vasu cestu. Samozrejme ak mate extremne slaby GPS signal, moze sa stat to, ze fiktivne tu rychlost dosiahnete aj ked stojite doma pri okne. [Zistene z praxe, oficialne nepotvrdene]

4.) Klient nereportuje zapchu ako taku. Klient moze reportovat iba event "zapcha", ktory ale ma iba minimalny vplyv na routing (podla oficialnych vyjadreni zdvojnasobuje vahu zistenej rychlosti na oznacenom segmente). Co to ale vaha je, zatial oficialne nevieme a klebety tu sirit nebudem. [Zistene z praxe, dvojnasobna vaha oficialne potvrdena]

5.) Klient reportuje cas potrebny na prejdenie kazdeho segmentu na vasej trase. Ak servery uznaju, ze vypocitana rychlost na segmente je nestandardna, informuju real-time server ze ma oznacit segment farebnou ciarou. Robia to ale servery, nie klient. [Zistene z praxe a odchytavanim dat]

6.) Parametre ktore sa daju nastavit v konfiguraku bohuzial nic neriesia. Riesia iba to, kedy vam ma vyskocit okno "stojite v zapche?", bohuzial ale to okno nerobi nic ine, nez umiestnuje zapchovy event (ktory zdvojnasobuje vahu uz zistenej rychlosti). Toto sme naposledy analyzovali vo verzii 3.0, mozno sa odvtedy nieco zmenilo. [Zistene z praxe a oficialne potvrdene]

[vlado_s]

Pekne si sa rozpísal
Dnes sa mi podarilo vytvoriť zápchu s dvomi rôznymi rýchlosťami na jednom segmente. V strede bola 14km/h a pri kraji 7km/h. Screenshot nevyšiel, zachytil som biele pozadie. Predpokladám každá z rýchlostí bola v inom smere, v tom lejaku som nemal možnosť prevádzať nejakú analýzu.

[Glipko]

Ahojte priatelia,

Takze aby bolo jasno:

1.) INTL waze klient infrastruktura je v skratke tvorena dvomi oblacikmi - jeden z nich je tzv. "real-time server", ktory bezi na AWS. Ma na starosti prihlasovanie do klienta, zobrazovanie wazerov, zobrazovanie dat (zapchy a eventy), a preberanie vsetkych informacii od klientov. Druhy oblak je tzv. "routing server", ktory ma na starosti planovanie cesty najlepsou moznou trasou vzhladom na historicke a realtime data. Samozrejme je tam aj kopec dalsich ucelovych sucasti (ako napr. server ktory distribuuje map tiles pre klientov aj pre WME), ale to teraz nie je podstatne. [Zistene odchytavanim dat, studovanim zdrojaku, ciastocne z vyjadreni od waze]

2.) Cela infrastruktura bojuje s kapacitnymi problemami. Prakticky jedina cast ktora nimi netrpi je real-time server beziaci na AWS. Kvoli tymto problemom musia ajtaci z waze robit vela optimalizacnych opatreni. Preto im tak dlho trva implementacia novych funkcii - snazia sa aby zatial spolahlivo bezali aspon tie stare, co casto vedie az k extremnym opatreniam. Problem je, ze Waze o tomto nekomunikuje, dokonca ani s top wazermi. Vsetci dufame, ze coskoro sa to zlepsi. [Vlastne zistenia + zahmlene oficialne info]

A teraz podme k podstatnemu:

3.) Waze klient po zapnuti caka, kym dosiahnete urcitu rychlost (30? 40? km/h - neviem), cim sa potvrdi ze uz idete v aute. Az po tom reportuje real-time serveru vasu cestu. Samozrejme ak mate extremne slaby GPS signal, moze sa stat to, ze fiktivne tu rychlost dosiahnete aj ked stojite doma pri okne. [Zistene z praxe, oficialne nepotvrdene]

4.) Klient nereportuje zapchu ako taku. Klient moze reportovat iba event "zapcha", ktory ale ma iba minimalny vplyv na routing (podla oficialnych vyjadreni zdvojnasobuje vahu zistenej rychlosti na oznacenom segmente). Co to ale vaha je, zatial oficialne nevieme a klebety tu sirit nebudem. [Zistene z praxe, dvojnasobna vaha oficialne potvrdena]

5.) Klient reportuje cas potrebny na prejdenie kazdeho segmentu na vasej trase. Ak servery uznaju, ze vypocitana rychlost na segmente je nestandardna, informuju real-time server ze ma oznacit segment farebnou ciarou. Robia to ale servery, nie klient. [Zistene z praxe a odchytavanim dat]

6.) Parametre ktore sa daju nastavit v konfiguraku bohuzial nic neriesia. Riesia iba to, kedy vam ma vyskocit okno "stojite v zapche?", bohuzial ale to okno nerobi nic ine, nez umiestnuje zapchovy event (ktory zdvojnasobuje vahu uz zistenej rychlosti). Toto sme naposledy analyzovali vo verzii 3.0, mozno sa odvtedy nieco zmenilo. [Zistene z praxe a oficialne potvrdene]

Dakujem za skvele zhrnutie.

1 a 2 som uz viac-menej vypozoroval. K zaveru bodu 2, v co dufate, ze sa zlepsi kapacita infrastruktury, alebo komunikacia Waze?

3 - ta rychlost bude zrejme mensia, kedze nie je problem vyrobit reporty na korculiach, skusim otestovat.

4 - je mi jasne, ze event zapchu nerobi, maximalne jej malicko pomoze.

5 - no a teraz to zacina byt zaujimave, co presne klient posiela? timestampy na junctions? cas za ktory presiel segment? alebo priebezne data o polohe, nech si to servre preberu same? snazim sa skompilovat 2.4 klienta (zatial neuspesne) a potom by som sa v nom rad trosku porypal a upravil ho aby vyrabal zapchy takze kazde nakopnutie pomoze

6 - hej, konfigurak som pozeral a ziadne slubne vyzerajuce parametre ani v 3.2 nie su

no a este nech zhrniem k comu som zatial dospel - neupraveny klient v prednom sprievodnom vozidle je na figu, vzhladom na priemerky co budu na segmentoch v centre (btw. kde si ich viem pozriet?) ide pomerne rychlo a potom zas stoji niekde pred krizovatkou a caka kym to "zadok" dobehne, co zjavne servre vyhodnotia ako normalnu jazdu. klienti co sme mali na korculiach/kolobezke mali dost podobne chovanie, kedze blokujeme krizovatky a potom sa snazime rychlo dostat dopredu - preto zrejme obcas zapchu hodilo, ked to rychlo nebolo dost rychlo takze skusim to v piatok (ak pocasie dopraje) spravit inak - drzat sa niekde v strede davu a ist plynulo pomaly. ak to bude fungovat a podari sa mi toho klienta skompilovat, tak ho skusim upravit aby simuloval podobne chovanie na prejdenej trase.

[guri211]

1 a 2 som uz viac-menej vypozoroval. K zaveru bodu 2, v co dufate, ze sa zlepsi kapacita infrastruktury, alebo komunikacia Waze?

Kapacita, ale ta komunikacia by sa mohla tiez

5 - no a teraz to zacina byt zaujimave, co presne klient posiela? timestampy na junctions? cas za ktory presiel segment? alebo priebezne data o polohe, nech si to servre preberu same? snazim sa skompilovat 2.4 klienta (zatial neuspesne) a potom by som sa v nom rad trosku porypal a upravil ho aby vyrabal zapchy takze kazde nakopnutie pomoze

Priklad:

Code: Select all

DATE: Tue Jun 12 16:47:19 CEST 2012
URL: /rtserver/distrib/command
IP: 85.237.224.45
WUID: 311450657 LON: 17181262 LAT: 48196322
UID,311450657,zD63DBwGgKqW2mXKM
At,17.181262,48.196322,0.000180,84,1,153039280,155825690,T
MapDisplayed,17.217212,48.206576,17.219608,48.191332,17.179260,48.194636,17.178782,48.197748,17.186872,48.196744,2789
GPSPath,Default,1339512426,12,17.178654,48.196254,180,0,17.178863,48.196228,180,1,17.179500,48.196186,180,3,17.181048,48.196
NodePath,1339512394,4,148240347,0,153039280,32

At: Tvoja poloha (kde ma zobrazit tvojho panacika), azimut, zvysok budu ID segmentov / junctions a nejake stavove info;
MapDisplayed: Vyrez 2D/3D mapy ktory mas zobrazeny (aby server vedel pre ktory vyrez ti ma poslat eventy)
GPSPath: Tvoja cesta ktoru si presiel od posledneho updatu;
NotePath: Rovnako tvoja cesta ktoru si presiel od posledneho updatu, ale s ID segmentov / junctions a zrejme poctom sekund.

Ak by si mal zaujem, mozme dat k tomu stretko.