PDA

View Full Version : Delayed command action



cliveb
2007-10-26, 08:58
This has been noted and discussed a bit in previous threads, but I just wanted to bring up this issue once again. I'm not trying to be negative, and am genuinely interested in seeing Jive succeed (if it works well, my wife will love it). What follows is offered as constructive criticism, albeit delivered as assertively as possible while remaining polite, because I think this issue is *so* important.

I believe there is something fundamentally wrong with the way that Jive commands are acted upon by the server. I've just been playing around with the latest firmware (r743) and once again a series of commands appeared to be ignored/lost, only for them to execute after a long delay (it felt like at least a minute, but I suppose it was actually tens of seconds).

Now, this may be something to do with wireless networking issues. (Or it might be to do with the server being overloaded at the time, but I don't think so in this case). But whatever the cause, having a remote control device behave like this is utterly confusing. Slim Devices *cannot* rely on users getting their wireless networks and/or servers running so perfectly that it's never an issue.

I think people are prepared to accept that sometimes a remote command doesn't get through. When that happens, they repeat it. What they don't expect to happen is that the commands get stacked up and then executed some time later. A solution has to be found for this - I believe if this behaviour remains it will be fatal to Jive's usability.

Ideally the server needs to be able to know how much time has elapsed since the command was sent by Jive, and if it's more than a very short time (eg. half a second), quietly ignore it. But as far as I can see, that would require very accurate synchronised clocks between SlimServer and Jive, and I suspect that's not likely. What is the granularity of the Jive's clock? Is it feasible for SlimServer to reset Jive's clock every few seconds so that commands can be reliably timestamped?

dean
2007-10-26, 10:19
Clive,

Are you seeing this on the Jive hardware platform and the desktop
software versions?

There are some serious performance problems in the JHB hardware due
to bugs in the current kernel. Next week we'll be rolling out a new
version with a new kernel that improves things dramatically.

If you have the time, Richard posted a one-off build of the JHB
software in the developer campfire area: https://
slimdevices.campfirenow.com/room/48940/transcript/2007/10/19 before
he went on vacation. Otherwise, look for the new version next week.

-dean

snarlydwarf
2007-10-26, 11:55
Ideally the server needs to be able to know how much time has elapsed since the command was sent by Jive, and if it's more than a very short time (eg. half a second), quietly ignore it. But as far as I can see, that would require very accurate synchronised clocks between SlimServer and Jive, and I suspect that's not likely. What is the granularity of the Jive's clock? Is it feasible for SlimServer to reset Jive's clock every few seconds so that commands can be reliably timestamped?

Right, I agree with that: or in networking terms... a normal IR remote that humans are used to uses the equivalent of UDP... packets may or may not get to the reciever (sunlight, someone walking in front of you, reflection of glass, etc..) while the Jive uses TCP (literally), ensuring packets will get through even if delayed. That creates a dichotomy in what the user is 'used to' and what really happens. (It happens to some extent with a wireless SB still, but the SB has room for larger gain antennas than Jive.)

The Jive does talk to the server very very often (turn on the JSON debugging to see this), so it shouldn't be too hard to have a generic Jiffy count or something so that "old" packets don't get delayed.

JimC
2007-10-26, 13:34
Right, I agree with that: or in networking terms... a normal IR remote that humans are used to uses the equivalent of UDP... packets may or may not get to the reciever (sunlight, someone walking in front of you, reflection of glass, etc..) while the Jive uses TCP (literally), ensuring packets will get through even if delayed. That creates a dichotomy in what the user is 'used to' and what really happens. (It happens to some extent with a wireless SB still, but the SB has room for larger gain antennas than Jive.)

The Jive does talk to the server very very often (turn on the JSON debugging to see this), so it shouldn't be too hard to have a generic Jiffy count or something so that "old" packets don't get delayed.

Forgive a marketing guy's input on a technical issue, but can't we simply set a short TTL for Jive's outbound packets? Wouldn't the stack handle the problem for us that way? For specific packets types that should live a little longer (certain ACKs, perhaps?) we could set the TTL high enough to ensure they get through appropriately.

Or am I just way off base here?


-=> Jim "Potentially packet-challenged" Carlton

dean
2007-10-26, 13:40
On Oct 26, 2007, at 1:34 PM, JimC wrote:
> Forgive a marketing guy's input on a technical issue, but can't we
> simply set a short TTL for Jive's outbound packets? Wouldn't the
> stack
> handle the problem for us that way? For specific packets types that
> should live a little longer (certain ACKs, perhaps?) we could set the
> TTL high enough to ensure they get through appropriately.
>
> Or am I just way off base here?
Probably. :)

The problem isn't at the TCP level, rather it's a performance issue
on either or both the Jive and the host computer. The new kernel and
antenna that are coming will make a huge difference here. Let's see
how it works after we get those upgraded.

-dean

snarlydwarf
2007-10-26, 13:49
Forgive a marketing guy's input on a technical issue, but can't we simply set a short TTL for Jive's outbound packets? Wouldn't the stack handle the problem for us that way? For specific packets types that should live a little longer (certain ACKs, perhaps?) we could set the TTL high enough to ensure they get through appropriately.

Or am I just way off base here?


TTL on networks isn't really Time... they call it Time just to confuse marketing people. (Actually, that is the real goal of most networking types: confusing the marketing people.) It is really "number of router hops"... That is how traceroute works: it sends a packet to a remote machine but starts with a TTL of 1, so the first router returns "drat, i tried, but when I decremented the hop count, I couldnt send it on". traceroute increases the TTL, and then gets the time to the next router, which will give up, etc.

cliveb
2007-10-27, 01:42
Are you seeing this on the Jive hardware platform and the desktop
software versions?
Only on the Jive hardware. I haven't yet built the software emulator. (I'm a Windows user, but try to avoid Microsoft development tools, so Visual Studio is new to me. After one aborted attempt to build Jive, I didn't have the time to start investigating so put it to one side).


There are some serious performance problems in the JHB hardware due to bugs in the current kernel. Next week we'll be rolling out a new version with a new kernel that improves things dramatically.
OK, that's good to hear. Obviously any performance improvement is welcome, but the basic point I was trying to make is a matter of principle: that remote commands that cannot be executed immediately should be discarded rather than queued.

cliveb
2007-10-27, 01:57
Right, I agree with that: or in networking terms... a normal IR remote that humans are used to uses the equivalent of UDP... packets may or may not get to the reciever (sunlight, someone walking in front of you, reflection of glass, etc..) while the Jive uses TCP (literally), ensuring packets will get through even if delayed.
While I was composing my original post, I did initially include a paragraph suggesting that outgoing commands should use UDP instead of TCP, but then realised that:

1. I really don't know enough about the fine details to present my thoughts authoritatively. It isn't just a matter of using UDP to avoid retransmission - surely UDP packets can be delayed and still arrive? We need some way for SlimServer to decide to ignore a delayed packet even though it does get through. (Or perhaps in the context of a home LAN, any UDP packet that does arrive is bound to have arrived quickly, so that's not actually an issue after all?. But then there's still SqueezeNetwork to consider - which I tend to forget since I don't use it)

2. It's probably not feasible for Jive to talk UDP in any case. I get the impression that the Jive/SlimServer protocol is something called JSON (which I don't know about) wrapped inside an HTTP transaction (which I do know about). If it does use HTTP as the "transport mechanism", then we're stuck with TCP. Hence the need for some kind of timestamp so that SlimServer can ignore delayed commands.


The Jive does talk to the server very very often (turn on the JSON debugging to see this), so it shouldn't be too hard to have a generic Jiffy count or something so that "old" packets don't get delayed.
Interesting. Perhaps some of the Jive development experts might be able to comment on whether any kind of mechanism to ignore delayed packets is feasible?

But before that, I guess the first thing is to find out whether the majority even agree with my view that delayed commands should be ignored?

Triode
2007-10-27, 05:17
I think TCP is the right transport mechanism - its used by slimproto for remote commands on existing players. There is a mechansim in slimserver to discard IR button presses which are too old. This should probably be considered for jive but the trick will be identifying which can be discarded.

Having spent some time profiling jive, the current delays are mainly within the remote itself so there is scope to significantly improve this by changes to the remote software. The main delay at present is due to the overhead of the lua threading library used in conjunction with the current kernel. The new linux kernel/thread library which Dean refers to is much better and gives a noticable improvement with the current application code. There are more things which can be done, including making more use of the priorisation mechansism in the software to identify and treat messages at high priority, but I think you will be impressed with difference the new kernel makes.

One note on this - the jive.bin image on campfire referred to by Dean will work as is on P8 jives, but not on P7 ones. If you don't know which one you have you are probably best waiting for Richard to work on seemless upgrade process.