STM32F4 LWIP rychlost

Marek Sembol hwm.land na gmail.com
Neděle Duben 21 12:33:44 CEST 2013


Respektive - podival jsem se do dokumentace na ReceiveFrom a ten port 0 je
zda se OK, ale musite si ten socket nabidnovat pomoci Bind
Marek


2013/4/21 Marek Sembol <hwm.land na gmail.com>

> 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/24721341/attachment-0001.htm>


Další informace o konferenci Hw-list