Lång tid att skicka kommandon

Moderator: Telldus

erikr
Posts: 12
Joined: Fri Mar 17, 2023 9:45 am
Location: Stockholm

Post by erikr »

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.
zyberzero
Posts: 56
Joined: Fri Mar 17, 2023 9:45 am
Location: Göteborg

Post by zyberzero »

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.)
micke.prag
Site Admin
Posts: 2243
Joined: Fri Mar 17, 2023 9:45 am
Location: Lund
Contact:

Post by micke.prag »

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.
Micke Prag
Software
Telldus Technologies
zyberzero
Posts: 56
Joined: Fri Mar 17, 2023 9:45 am
Location: Göteborg

Post by zyberzero »

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.

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
zyberzero
Posts: 56
Joined: Fri Mar 17, 2023 9:45 am
Location: Göteborg

Post by zyberzero »

Tjena!
Nu när det har gått ett antal månader sen sist så undrar jag om ni kikar på det här. Jag har iallafall inte märkt någon skillnad i 2.0.2 mot 2.0.1-

Tack på förhand!
/zyber
micke.prag
Site Admin
Posts: 2243
Joined: Fri Mar 17, 2023 9:45 am
Location: Lund
Contact:

Post by micke.prag »

I version 2.1 kommer TellStick att vara öppen hela tiden och på vissa plattformar märks det tydliga skillnader. Tyvärr har jag ingen möjlighet att benchmarka här.

Och, nej, jag kan inte säga när 2.1 släpps.
Micke Prag
Software
Telldus Technologies
zyberzero
Posts: 56
Joined: Fri Mar 17, 2023 9:45 am
Location: Göteborg

Post by zyberzero »

OK - tack!
Ingår Linux (Ubuntu, x64) i de plattformar där det gör skillnad?
Finns dessa ändringar att tillgå i SVN än, eller är det att skriva själv som gäller?
micke.prag
Site Admin
Posts: 2243
Joined: Fri Mar 17, 2023 9:45 am
Location: Lund
Contact:

Post by micke.prag »

Allt finns i trunk. Kan dock varna att det är lite trickigt att få igång i Linux just nu...
Micke Prag
Software
Telldus Technologies
maglub
Posts: 2
Joined: Fri Mar 17, 2023 9:45 am

Re: Lång tid att skicka kommandon

Post by maglub »

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.
Hej,

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
Så, i princip är det ingen skillnad mellan att köra kommandon ett efter ett eller tillsammans i ett kommando.
maglub
Posts: 2
Joined: Fri Mar 17, 2023 9:45 am

Re: Lång tid att skicka kommandon

Post by maglub »

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

Code: Select all

malu@xbmc:/home/malu/test $strace tdtool --on 1 2>&1 | grep nanosleep | wc -l
445
Typisk read.

Code: Select all

nanosleep({0, 1000000}, NULL)           = 0
read(3, "", 1)                          = 0
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 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
jonaz
Posts: 46
Joined: Fri Mar 17, 2023 9:45 am

Re: Lång tid att skicka kommandon

Post by jonaz »

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.
hne
Posts: 7
Joined: Fri Mar 17, 2023 9:45 am

Re: Lång tid att skicka kommandon

Post by hne »

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

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

Code: Select all

std::wstring clientMessage = d->eventSocket.read(1000); //testing 5 second timeout
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.
micke.prag
Site Admin
Posts: 2243
Joined: Fri Mar 17, 2023 9:45 am
Location: Lund
Contact:

Re: Lång tid att skicka kommandon

Post by micke.prag »

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
Du är mer än välkommen att hjälpa både dig och andra genom att skicka in förbättringar:
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
hne
Posts: 7
Joined: Fri Mar 17, 2023 9:45 am

Re: Lång tid att skicka kommandon

Post by hne »

micke.prag wrote:
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
Du är mer än välkommen att hjälpa både dig och andra genom att skicka in förbättringar:
http://developer.telldus.com/wiki/Guides/Contributing

Ang. timeouten så finns detta i planeringen:
http://developer.telldus.com/ticket/157
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.
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.
Post Reply