Lång tid att skicka kommandon
Moderator: Telldus
Jag tycker det här är väldigt spännande.. Har ni kört någon profilering som visar vart tiden på 1,5 -2 sekunder spenderas? Inte kan det vara öppning och stängning av filen väl? Kanske sättning av attributen är lite segt? Eller är det i pinnen problemet sitter? Tja.. svårt (och onödigt) att gissa
Det vore ju fint om man kunde korta ner lite på det hela. När man dimmar en lampa så är det ju en feedbackloop som snurrar på där människan är inblandad och sådana (i alla fall den här) brukar bli lite otåliga av att vänta flera sekunder för att justera in rätt nivå.
Medan ni letar efter fördröjningen i koden så får jag hitta på ett sätt att lösa det så effektivt som möjligt för användaren i gränssnittet..
väntar med spänning på mer information om det dyker upp någon.
Det vore ju fint om man kunde korta ner lite på det hela. När man dimmar en lampa så är det ju en feedbackloop som snurrar på där människan är inblandad och sådana (i alla fall den här) brukar bli lite otåliga av att vänta flera sekunder för att justera in rätt nivå.
Medan ni letar efter fördröjningen i koden så får jag hitta på ett sätt att lösa det så effektivt som möjligt för användaren i gränssnittet..
väntar med spänning på mer information om det dyker upp någon.
Jag vet inte var problemet ligger, men jag tror det är öppning och speciellt stängning som tar tid - det går fort från att jag exekverar tdtool till att ändringen slutförs men sen går det fortfarande 1-1.5 sek tills tdtool termineras. Jämför jag med en fjärrkontroll hinner jag switcha läge ~10 ggr/sek = 0.1 sek / kommando. (enbart on och off, på en sartanokompatibel enhet, mot tdtool som tar nästan 0.7 sek för samma sak.)
-
- Site Admin
- Posts: 2243
- Joined: Fri Mar 17, 2023 9:45 am
- Location: Lund
- Contact:
Just nu kör jag inte linux och då blir det lite roliga resultat:
Windows XP, Senaste mjukvaran (dock genom cygwin för att få timekommandot), samma sticka och maskin som tidigare.
Windows XP, Senaste mjukvaran (dock genom cygwin för att få timekommandot), samma sticka och maskin som tidigare.
Code: Select all
zyber@jake /cygdrive/c/Program/Telldus
$ time ./tdtool.exe --on 3
Turning on device 3, on - Success
real 0m1.017s
user 0m0.015s
sys 0m0.015s
zyber@jake /cygdrive/c/Program/Telldus
$ time ./tdtool.exe --on 3 --off 3 --on 3 --off 3
Turning on device 3, on - Success
Turning off device 3, off - Success
Turning on device 3, on - Success
Turning off device 3, off - Success
real 0m3.945s
user 0m0.015s
sys 0m0.015s
-
- Site Admin
- Posts: 2243
- Joined: Fri Mar 17, 2023 9:45 am
- Location: Lund
- Contact:
-
- Site Admin
- Posts: 2243
- Joined: Fri Mar 17, 2023 9:45 am
- Location: Lund
- Contact:
Re: Lång tid att skicka kommandon
Hej,Om ni kör tdtool --on 1 --off 1 --on 1 --off 1
Hur påverkas tiden då?
TellStick öppnas och stängs mellan varje ändå men det kan vara intressant att jämföra.
Det kanske är lite sent att svara på det här, men jag gjorde det här nyss:
Code: Select all
malu@xbmc:/home/malu/test $tdtool --version
tdtool 2.0.3
Copyright (C) 2009 Telldus Technologies AB
Written by Micke Prag <micke.prag@telldus.se>
malu@xbmc:/home/malu/test $cat bapp.ksh
#!/bin/ksh
echo "#----------- 4 tdtools each timed in a row"
time tdtool --on 1
time tdtool --off 1
time tdtool --on 1
time tdtool --off 1
echo "#----------- 4 tdtool in a row"
time {
tdtool --on 1; tdtool --off 1; tdtool --on 1; tdtool --off 1
}
echo "#----------- 4 tdtool commands in one invocation"
time tdtool --on 1 --off 1 --on 1 --off 1
malu@xbmc:/home/malu/test $./bapp.ksh
#----------- 4 tdtools each timed in a row
Turning on device 1, TV-lampan - Success
real 0m0.65s
user 0m0.00s
sys 0m0.00s
Turning off device 1, TV-lampan - Success
real 0m0.64s
user 0m0.00s
sys 0m0.01s
Turning on device 1, TV-lampan - Success
real 0m0.65s
user 0m0.00s
sys 0m0.01s
Turning off device 1, TV-lampan - Success
real 0m0.65s
user 0m0.00s
sys 0m0.01s
#----------- 4 tdtool in a row
Turning on device 1, TV-lampan - Success
Turning off device 1, TV-lampan - Success
Turning on device 1, TV-lampan - Success
Turning off device 1, TV-lampan - Success
real 0m2.55s
user 0m0.02s
sys 0m0.05s
#----------- 4 tdtool commands in one invocation
Turning on device 1, TV-lampan - Success
Turning off device 1, TV-lampan - Success
Turning on device 1, TV-lampan - Success
Turning off device 1, TV-lampan - Success
real 0m2.54s
user 0m0.01s
sys 0m0.05s
Re: Lång tid att skicka kommandon
Och det verkar som att större delen av tiden som det tar (0.6 - 0.7 sekunder) för att köra kommandot, är nanosleep()
Typisk read.
Om man filtrerar bort alla read, som ger return code 0, så får man följande:
Code: Select all
malu@xbmc:/home/malu/test $strace tdtool --on 1 2>&1 | grep nanosleep | wc -l
445
Code: Select all
nanosleep({0, 1000000}, NULL) = 0
read(3, "", 1) = 0
Code: Select all
malu@xbmc:/home/malu/test $strace tdtool --on 1 2>&1 | grep read | grep 3 | grep -v 0
read(3, "deviceNode = \"/dev/tellstick\"\nde"..., 8192) = 438
read(3, "device \"1\" {\n state = 1\n # sta"..., 8192) = 141
read(3, "+", 1) = 1
read(3, "S", 1) = 1
read(3, "\r", 1) = 1
read(3, "\n", 1) = 1
Re: Lång tid att skicka kommandon
Blev detta löst?
Jag kör 2.1.1 och tycker det tar lika lång tid att skicka som det alltid gjort. Har en ny Tellstick Duo som jag fick hem förra veckan.
Jag kör 2.1.1 och tycker det tar lika lång tid att skicka som det alltid gjort. Har en ny Tellstick Duo som jag fick hem förra veckan.
Re: Lång tid att skicka kommandon
Även 2.1.1 gör riktigt håriga saker med mutexar spritslat runt kod som kör select i while(1) i Socket_unix.cpp. Nog för att det är svårt att skriva portabel kod, men jag är uppriktigt sagt förvånad att den där koden öht fungerar så bra som den ändå gör, och då är den ändå "bara" för unix-liknande system. Den kollar till exempel timeval efter select, vilket man inte bör göra om man vill att det ska fungera på något annat än linux. Däremot kollas inte errno och om select returnerar 0 eller -1 verkar inte heller göras skillnad på...
För att prova vad som tar tid, gör ett enkelt timingtestprogram:
Skippar man tdClose tar det precis en sekund mindre. Om man inte anropar ngt mellan tdInit och tdClose tar det precis en sekund mindre. Enda koden jag hittar som har ngt att göra med en sekund som jag kan hitta är och jag misstänker att någon tänkt Fel i just hanteringen runt select inne i Socket_unix.cpp i read(int)-metoden.
Edit: det spelar alltså ingen roll om man har ngn hårdvara ansluten, så länge man frågar telldusd något kommer tdClose() att ta en sekund. Om tdtool gör tdInit() och tdClose() runt varje kommando kommer varje kommando ta en onödig sekund. Tar jag bort tdClose() från ovanstående och kör programmet 1000 gånger tar det totalt 9.890s och telldusd tar 6% CPU. I kombination med körande TelldusCenter verkar det mindre stabilt och verkar hamna i ngn mer eller mindre oändlig loop, så något bra gör uppenbarligen tdClose() men jag kan inte utan vidare avgöra om det är pga att det finns en sleep som undviker race conditions någonstans eller för att något frigörs på rätt sätt bara om klienten avslutar korrekt. Jag hoppas på det förra...
Edit 2: Jag får "telldusd: Received SIGPIPE signal." repeterat lika många gånger i syslog som jag kör ngt som inte gör tdClose(). Lutar åt att schemalägga en restart av telldusd varje natt tills den här är löst.
För att prova vad som tar tid, gör ett enkelt timingtestprogram:
Code: Select all
#include <telldus-core.h>
int main(int argc, char **argv) {
tdInit();
int id = tdGetDeviceId(0);
int supported = tdMethods(id,TELLSTICK_TURNON | TELLSTICK_TURNOFF | TELLSTICK_DIM);
tdClose();
return 0;
}
Code: Select all
std::wstring clientMessage = d->eventSocket.read(1000); //testing 5 second timeout
Edit: det spelar alltså ingen roll om man har ngn hårdvara ansluten, så länge man frågar telldusd något kommer tdClose() att ta en sekund. Om tdtool gör tdInit() och tdClose() runt varje kommando kommer varje kommando ta en onödig sekund. Tar jag bort tdClose() från ovanstående och kör programmet 1000 gånger tar det totalt 9.890s och telldusd tar 6% CPU. I kombination med körande TelldusCenter verkar det mindre stabilt och verkar hamna i ngn mer eller mindre oändlig loop, så något bra gör uppenbarligen tdClose() men jag kan inte utan vidare avgöra om det är pga att det finns en sleep som undviker race conditions någonstans eller för att något frigörs på rätt sätt bara om klienten avslutar korrekt. Jag hoppas på det förra...
Edit 2: Jag får "telldusd: Received SIGPIPE signal." repeterat lika många gånger i syslog som jag kör ngt som inte gör tdClose(). Lutar åt att schemalägga en restart av telldusd varje natt tills den här är löst.
-
- Site Admin
- Posts: 2243
- Joined: Fri Mar 17, 2023 9:45 am
- Location: Lund
- Contact:
Re: Lång tid att skicka kommandon
Du är mer än välkommen att hjälpa både dig och andra genom att skicka in förbättringar:hne wrote:Även 2.1.1 gör riktigt håriga saker med mutexar spritslat runt kod som kör select i while(1) i Socket_unix.cpp
http://developer.telldus.com/wiki/Guides/Contributing
Ang. timeouten så finns detta i planeringen:
http://developer.telldus.com/ticket/157
Micke Prag
Software
Telldus Technologies
Software
Telldus Technologies
Re: Lång tid att skicka kommandon
Tack, jag visste att jag sett den där någonstans. Nu vet jag var jag har den och lyckas jag hitta en snygg lösning ska jag absolut dela med mig.micke.prag wrote:Du är mer än välkommen att hjälpa både dig och andra genom att skicka in förbättringar:hne wrote:Även 2.1.1 gör riktigt håriga saker med mutexar spritslat runt kod som kör select i while(1) i Socket_unix.cpp
http://developer.telldus.com/wiki/Guides/Contributing
Ang. timeouten så finns detta i planeringen:
http://developer.telldus.com/ticket/157
En modell skulle kunna vara att använda pselect istf select och använda en signal för att avbryta väntandet på indata? Jag har inte lurat ut ännu hur alla mutexar fungerar med multitrådade progam, så det kan mycket väl hända att inte heller det skulle fungera. Om serverdelen skickade ett avslutande meddelande skulle det heller inte behöva timeas ut. En tredje lösning, som brukar användas om man inte har pselect, är att sändande del av klienten får ha en pipe som mottagande del lyssnar på. Ska se om jag kan lyckas sno ihop något i helgen.
Och, jag ber om ursäkt för att jag uttryckt mig plumpt.