STM32F4 LWIP rychlost

Zuffa Jan ZuffaJ na cgc.sk
Neděle Duben 21 13:35:01 CEST 2013 

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 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

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

Další informace o konferenci Hw-list