STM32F4 LWIP rychlost

Neděle Duben 21 12:28:35 CEST 2013

Tak jen tak na prvni pohled:
a) ten prvni new Byte[1024] je zbytecny, ten Encoding si naalokuje sam
(nepodstatny detail)
b) jste si naprosto jisty, ze bude fungovat ReceiveFrom s portem 0? Mne se
to moc nezda (ale hadat se nebudu).

Marek

2013/4/21 Jaroslav Buchta <jaroslav.buchta na hascomp.cz>

>  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>
>
>>  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>
>>
>>> 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
>>>>> 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
>>>>
>>>
>>> _______________________________________________
>>> HW-list mailing list  -  sponsored by www.HW.cz
>>> Hw-list na list.hw.cz
>>> http://list.hw.cz/mailman/listinfo/hw-list
>>>
>>
>>
>>
>> _______________________________________________
>> HW-list mailing list  -  sponsored by www.HW.czHw-list na list.hw.czhttp://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
>>
>>
>
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.czHw-list na list.hw.czhttp://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/485b8754/attachment.htm>