STM32F4 LWIP rychlost

Jaroslav Buchta jaroslav.buchta na hascomp.cz
Neděle Duben 21 16:11:29 CEST 2013


No to zni jako rozumna pricina, to by vse vysvetlovalo...
Da se FW motivovat nejak z aplikace aby pruchod na nastaveny port povolil?
Ne ze by byl problem posilat obcas nejaky paket, ale jeden port jsem 
chtel mit jen na prijem proudu obrazovych dat a i ten prikazovy kanal po 
delsi prodleve obcas napoprve selze (asi je odpoved moc rychla)

Dne 21. 4. 2013 13:35, Zuffa Jan napsal(a):
>
> Mne to pripada na zapnuty firewall
>
> klient posle paket tak sa port vo fw otvori a potom
>
> to chvilu ide.
>
> j.
>
> *From:*hw-list-bounces na list.hw.cz [mailto:hw-list-bounces na list.hw.cz] 
> *On Behalf Of *Jaroslav Buchta
> *Sent:* Sunday, April 21, 2013 12:11 PM
> *To:* HW-news
> *Subject:* Re: STM32F4 LWIP rychlost
>
> No funguje to divne... Jeste me napada, jestli za to nahodou nemuzou 
> Win8... Kazdopadne po odeslani bajtu to prijima, po nejake dobe ne, 
> pak poslu prikaz - odpoved neprijme a po dalsim prikazu uz odpoved 
> prijme. Kdyz to zkousim z Hercules terminalu, tak to funguje jak z 
> praku. Navic na pouziti UdpClient snad neni co zkazit, proste new 
> UdpClient(lokalni port), a pak by IMHO hned melo fungovat Receive a 
> ono prd. Ani v ruznych variantach, kdy v konstruktoru pouziju EndPoint 
> s Ipaddress.Any atd.
>
> Kdyz bych pouzil primo Socket treba podle tohoto prikladu, je tam 
> nejaky zadrhel?  (ted nejsem na compu kde bych to mohl zkusit, protoze 
> popijim pivo na zahrade ;-) )
>
> {
> *byte*[] data = *new byte*[1024];
> string input, stringData;
> IPEndPoint ip = *new *IPEndPoint(IPAddress.Parse("127.0.0.1"), 9999);
>
> Socket server = *new 
> *Socket(AddressFamily.InterNetwork,SocketType.Dgram, ProtocolType.Udp);
>
> string welcome = "Hello";
> data = Encoding.ASCII.GetBytes(welcome);
> server.SendTo(data, data.Length, SocketFlags.None, ip);
>
> IPEndPoint sender = *new *IPEndPoint(IPAddress.Any, 0);
> EndPoint Remote = (EndPoint)sender;
>
> data = *new byte*[1024];
> *int *receivedDataLength = server.ReceiveFrom(data, ref Remote);
>
> Console.WriteLine("Message received from {0}:", Remote.ToString());
> Console.WriteLine(Encoding.ASCII.GetString(data, 0, receivedDataLength));
>
> server.Close();
> }
>
> Vypada to jednoduse a premyslim, v cem je zadrhel. Myslim, ze vzhledem 
> k pozadavku na vetsi objemy dat, cim na nizsi level pujdu, tim lip... 
> A se siti jsem v .NET jeste nedelal.
>
> Dne 21. 4. 2013 10:39, Marek Sembol napsal(a):
>
>     no mne to chovani prijde minimalne hodne zvlastni a asi bych
>     intenzivne hledal chybu u sebe. Pripadne bych opustil UdpClient a
>     pracoval primo se Socket. Ale fakt si myslim, ze za to .NET
>     nemuze. Podle mne trida Socket pouze zabali WinAPI a UdpClient
>     "zjednodusi" pouzivani Socket (spolu se specializaci na UDP a
>     radou omezeni)
>
>     Marek
>
>     2013/4/21 Jaroslav Buchta <jaroslav.buchta na hascomp.cz
>     <mailto:jaroslav.buchta na hascomp.cz>>
>
>     Ajo vidite, Close, to me nenapadlo ;-) Zkusim. Ale stejne to casem
>     asi udelam ve Win API, kdyz s tim polem bytu nebude problem.
>
>     Dne 21. 4. 2013 10:12, Marek Sembol napsal(a):
>
>         vyjadrim se jen castecne:)
>
>         Pokud pri tom volani z C# -> WinAPI ty "velke objemy dat" jsou
>         Byte[], tak ta konverze je prakticky zadarmo.
>
>         .NET si to pole proste jen prispendli v pameti a preda dal
>         ukazatel.
>
>         Synchronni vs. asynchronni - no tady se to asi nebude chovat
>         rozdilne. Ono to synchronni volani byva proste jen par volani
>         BeginAsyncXXX a EndAsyncXXX.
>
>         Aplikace se samozrejme ukoncit da. Staci treba zavrit ten
>         socket a volani prijmu skonci na vyjimku (a tu je mozno
>         osetrit, ze). Moznosti jak ten socket zavrit je cela rada.
>         Jako rekce na CTRL-C (pri konzolove aplikaci), jako reakci na
>         service-stop (pri service), jako volani naschedulovane pomoci
>         timeru (kdykoliv) a podobne.
>
>         Marek
>
>         2013/4/21 Jaroslav Buchta <jaroslav.buchta na hascomp.cz
>         <mailto:jaroslav.buchta na hascomp.cz>>
>
>         Diky za namety, zarizeni zda se funguje docela zpusobne, co
>         nefunguje podle predstav je trida .NET UdpClient na PC -
>         proste pokud neodeslu aspon bajt na zarizeni, nic neprijme a i
>         potom za nejaky timeout chcipne a pomuze az odeslani dalsiho
>         byte aby zase bylo neco prijmuto - nic jineho takze port atd.
>         je asi nasteveno spravne... Neni nejaka option, kterou jsem
>         zatim nepostrehnul, aby to fungovalo primitivne a jen cekalo,
>         az na port neco prijde??? Zkousel jsem uz vsechny mozne
>         varianty synchronni (tam je vtipne, ze Receive nema zadny
>         timeout a aplikace se nakonec ani neda ukoncit...) i
>         asynchronni. C# je dobre asi fakt jen na GUI...
>
>         Co zatim hledam, tak jsou s touto tridou jen problemy - je
>         jina cesta nez pouzit DLL kde to bude realizovano jako WinAPI
>         (coz by snad mohlo fungovat...) Zase konverze velkych objemu
>         dat do C# pak bude asi narocna na rezii...
>
>
>
>
>         Dne 21. 4. 2013 9:35, Ondrej napsal(a):
>
>             Někde v lwipopts.h jde nastavit max. velikost paketu.
>             1400B je velikost paketu (náhoda :-) - takže by se někde
>             měla ještě povolit fragmentace. Ale 100% jistý si tím
>             nejsem. Nicméně zrovna ST má pěkné PDF s návodem na lwip.
>             Byly tam myslím i nějaké testy rychlosti.
>
>             Add: ztrácení paketů: Nainstalujte si Wireshark a
>             zkontrolujte, jestli jsou pakety tam. To je naprostý
>             základ. Je docela slušná šance, že ST odesílat stíhá a
>             nestíhá přijímat jen program. Ono obecně odeslat UDP paket
>             není problém a to i na velkých rychlostech. Obvykle je
>             problém pak data napřijímat (ať už v PC nebo na uP).
>
>             Jinak UDP fragmentace smysl má a to velký. Pro velké toky
>             je problém přijímat 1400B pakety, ale pokud je fragmentuje
>             třeba na 14000B (10x větší), tak u to může PC stíhat. Už
>             jen třeba protože "callback" fce./přerušení se bude volat
>             10x méně často.
>
>             Ondřej
>
>             Dne 20.4.2013 22:54, Jaroslav Buchta napsal(a):
>
>             Mate nekdo zkusenost jak na to? Jednak jsem zjistil, ze je
>             nekde omezena velikost UDP paketu proste tak, ze pri
>             prekroceni to poskodi haldu a cele to jde do kytek,
>             hranice je nekde kolem 1400B
>             Dal je zajimave, ze kdyz odesilam pakety bezprostredne za
>             sebou, ztraceji se (ale az od nejakeho poctu a zalezi na
>             delce) a kdyz treba ted za kazdy 4. vlozim pauzu 1ms tak
>             to funguje OK (cili rychlost 4MB/s stabilne, coz mi prijde
>             OK, samozrejme prime pripojeni do pocitace)
>             Otazkou je, jestli se pakety ztraci u STM nebo na strane
>             PC... Ale na PC je gigabit, to by snad melo byt slusne
>             dimenzovane.
>             Dalsi zahada je u C# s UdpClient, dokud aspon bajt
>             nevyslu, nic neprijmu (i kdyz data na port prokazatelne
>             chodi, overeno hercules terminalem). To jsem v dokumentaci
>             nikde nenasel, melo by to snad fungovat pro prijem bez
>             volani Connect a Send, ne?
>
>             Jinak teda s rychlosti spokojenost, mozna by to slo i o
>             chlup vyse, prilezitostne vyzkousim. Taky by asi pomohlo
>             zvysit delku paketu - vi nekdo jak na to? Pochopil jsem,
>             ze jsou ruzne metody alokace pameti v LwIP.
>             _______________________________________________
>             HW-list mailing list  -  sponsored by www.HW.cz
>             <http://www.HW.cz>
>             Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
>             http://list.hw.cz/mailman/listinfo/hw-list
>
>
>             _______________________________________________
>             HW-list mailing list  -  sponsored by www.HW.cz
>             <http://www.HW.cz>
>             Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
>             http://list.hw.cz/mailman/listinfo/hw-list
>
>
>         _______________________________________________
>         HW-list mailing list  -  sponsored by www.HW.cz <http://www.HW.cz>
>         Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
>         http://list.hw.cz/mailman/listinfo/hw-list
>
>
>
>         _______________________________________________
>
>         HW-list mailing list  -  sponsored bywww.HW.cz  <http://www.HW.cz>
>
>         Hw-list na list.hw.cz  <mailto:Hw-list na list.hw.cz>
>
>         http://list.hw.cz/mailman/listinfo/hw-list
>
>
>     _______________________________________________
>     HW-list mailing list  -  sponsored by www.HW.cz <http://www.HW.cz>
>     Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
>     http://list.hw.cz/mailman/listinfo/hw-list
>
>
>
>
>     _______________________________________________
>
>     HW-list mailing list  -  sponsored bywww.HW.cz  <http://www.HW.cz>
>
>     Hw-list na list.hw.cz  <mailto:Hw-list na list.hw.cz>
>
>     http://list.hw.cz/mailman/listinfo/hw-list
>
>
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list

------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20130421/b16b4be7/attachment.htm>


Další informace o konferenci Hw-list