Page 2 of 2 FirstFirst 12
Results 21 to 35 of 35
  1. ptyork's Avatar
    Posts
    69 Posts
    Global Posts
    70 Global Posts
    #21  
    Quote Originally Posted by Chatter
    Yes, it's increased to 7200 (120 minutes).
    Sheesh! It took me like 5 minutes to retract my question and you'd already replied by the time I posted it. You are quite quick, my friend! Thanks, as always, for great customer service!
  2. aldamon's Avatar
    Posts
    650 Posts
    Global Posts
    684 Global Posts
    #22  
    Quote Originally Posted by ptyork
    Marc, nevermind, I see you already increased the maximum to 7199, which is certainly sufficient.

    Aldamon, use the console in Chatter and enter IDLETIME (seconds) where "(seconds)" is the number of seconds to wait before issuing the "ping." For example, entering IDLETIME 3600 would set the time between pings to 3600 seconds or 1 hour.

    Paul
    "Unrecognized command" in v1.1rc8.

    EDIT: idletime needs to be lowercase

    Quote Originally Posted by ptyork
    Setting it to a higher value will of course result in a potential delay of whatever this new value is. It's a tradeoff.

    Marc, of course you can use what I've written in any way you'd like. No worries.
    I changed mine to 1200 to have it check every 20 minutes. I might change it to 1800. We'll see how it goes. I agree with what you said in the other thread. I like the idea of having more battery life and fewer missed calls every hour of every day at the expense of the occasional hiccup with delayed delivery because of a reset timer. I think that's a very good tradeoff.

    Ignoring the "resetting timer" issue for a minute, has anyone ever called Fastmail and asked them what the idletime should be set to?
    Last edited by aldamon; 09/20/2005 at 06:08 PM.
  3. #23  
    FM is an hour, I believe.

    Marc
  4. aldamon's Avatar
    Posts
    650 Posts
    Global Posts
    684 Global Posts
    #24  
    Wow, if that's the case then setting idletime to 30 minutes would be optimal with Fastmail. My math could be wrong though. It's not my strong suit
  5. #25  
    You could try that (1800); just remember the tradeoff...

    Marc
  6. aldamon's Avatar
    Posts
    650 Posts
    Global Posts
    684 Global Posts
    #26  
    Correct me if I'm wrong, but if FM has a timeout of 60 minutes, and I set idletime to 30 minutes, I could experience a hiccup after 29 minutes of counting down, go another full 30 minutes with the reset counter, and still be OK. I wouldn't be protected from two consecutive hiccups though.
  7. #27  
    I don't know what you mean by hiccup.

    Marc
  8. aldamon's Avatar
    Posts
    650 Posts
    Global Posts
    684 Global Posts
    #28  
    Sorry:

    "that even if a network error occurs immediately after the IDLE request"

    Basically, whatever it takes to reset the timer.
  9. #29  
    The worst case is that the connection is dropped right after going IDLE, in which case it could take idletime seconds to figure it out and reconnect.

    Marc
  10. aldamon's Avatar
    Posts
    650 Posts
    Global Posts
    684 Global Posts
    #30  
    I see. So I had it backwards. Figures. It's still worth the trade-off IMO.

    So far this morning I've been using the 30-minute idletime (along with Efficient Sync which I've always had enabled) and my battery life is noticably better. I've sent myself a few test messages to see if everything was still working and there hasn't been a delay yet. I'm defintely not a power user. I don't get a ton of E-mails, but I like getting them immediately. Like everyone has said, this tweak will not help a power user with a busy data connection, but it's certainly helping me by eliminating 4 unneeded pings/connections an hour on an otherwise dormant connection.

    This might be a stupid question, but what kinds of things would cause the connection to drop in the first place? Are they complicated or are they things I could recognize and address manually?
  11. #31  
    Bad signal mostly.

    Marc
  12. ptyork's Avatar
    Posts
    69 Posts
    Global Posts
    70 Global Posts
    #32  
    My understanding of the connectivity between server and client in a mobile world is that there are essentially two hops. There is the "standard" hard-wired connection between the server and a "mobile gateway" (I'm quoting this because very likely this is the wrong term) that is managed by the carrier and a connection between the gateway and the phone. The IDLE connection (open socket) is actually maintained between the gateway and the server, not directly between the phone and the server. The gateway receives notifications on the open socket and signals the phone to connect to receive the data. Likewise, the phone signals the gateway that it has data for the socket (or to create a new socket or whatever) and sends its data via the gateway.

    Anyway, the point of this is that it is likely that the IDLE command's open socket will survive a signal drop between the phone and the tower/gateway as long as there is no active data connection between them. I don't THINK the towers even know if the phone is unavailable unless there is a need to route data to the phone (voice or data), so losing a signal on the handheld wouldn't immediately result in a disconnected socket. Obviously, once the gateway "knows" that the signal is lost, either by unsuccessfully trying to send data to the device or the device notifying the gateway of a desire to disconnect, then the gateway will close this and all other open sockets. So, "hiccups" are probably less common than one might think, requiring that the physical connection between server and gateway be disrupted somehow, not simply a drop in connectivity between phone and tower/gateway.

    Note that this is why you have three network states: disconnected, connected, and active. Disconnected (no arrows), the gateway server doesn't have to serve as a proxy between phone and server and can release resources. Connected (gray arrows), the gateway is required to maintain its proxy role, holding an IP address and any open sockets. Active (green arrows), the phone is directly connected to the gateway.

    This is my interpretation and is likely over simplified and possibly incorrect in some areas, but I think it is mostly right.

    Paul
  13. aldamon's Avatar
    Posts
    650 Posts
    Global Posts
    684 Global Posts
    #33  
    OK, that's what I thought was going on. So then why is the worst case scenario a lost connection right after going IDLE? The server is going to still think the IDLE connection is live until its timer runs out no matter what happens to Chatter. Doesn't this make the worst-case scenario a disconnection a minute before the next scheduled ping, instead of right after the last ping? Does Chatter somehow not know when it has lost an IDLE connection? I thought it always tried to reconnect itself.

    EDIT: I'm going to stop trying to wrap my brain around this and just enjoy the extra battery life. Thanks guys.
    Last edited by aldamon; 09/21/2005 at 12:17 PM.
  14. dwman's Avatar
    Posts
    896 Posts
    Global Posts
    907 Global Posts
    #34  
    One thing I discovered is that if you have two or more inboxes, you can have battery drain while having one connected while the other one is trying to connect unsuccesfully. This can ravage your battery life as I discovered yesterday.

    Bottom line. If you have more then one mailbox, make sure one of them isn't trying to connect for hours at a time.
  15. aldamon's Avatar
    Posts
    650 Posts
    Global Posts
    684 Global Posts
    #35  
    So far this morning, my Treo has been off of USB power for 2:45 and I'm sitting at 91% battery. Chatter is monitoring two Fastmail inboxes using an idletime of 1800 with Efficient Sync enabled. I've received four E-mails (no delay in service due to an 1800 idletime according to the timestamps), no phone calls, used 4Cast once, used Blazer once for an HTML message, had the screen on for ten minutes recategorizing apps, and have hotsynced once to install the latest Chatter RC. I average 1 bar of signal strength at work so the phone has to work a bit to stay connected. I'd say 91% is pretty damn good Now I just have to stay off Nesem at lunch. That really eats my battery. LOL.

    Thanks guys.
Page 2 of 2 FirstFirst 12

Posting Permissions