[PATCH 2/3] cxacru: Poll for device status more frequently.

[PATCH 2/3] cxacru: Poll for device status more frequently.

[Simon Arlott]

The device is only polled for status every 5 seconds yet status updates occur as often as every second - when the line is down the status changes between "down" and "attempting to activate" every 2 seconds.

Signed-off-by: Simon Arlott <simon@fire.lp0.eu>

---
 drivers/usb/atm/cxacru.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/atm/cxacru.c b/drivers/usb/atm/cxacru.c
index c1f97a3..a30cd9b 100644
--- a/drivers/usb/atm/cxacru.c
+++ b/drivers/usb/atm/cxacru.c
@@ -64,7 +64,7 @@ #define BR_STACK_ADDR	0x00187f10
 #define SDRAM_ENA	0x1
 
 #define CMD_TIMEOUT	2000	/* msecs */
-#define POLL_INTERVAL	5000	/* msecs */
+#define POLL_INTERVAL	500	/* msecs */
 
 /* commands for interaction with the modem through the control channel before
  * firmware is loaded  */
-- 
1.4.3.1


-- 
Simon Arlott (subscribed to lkml, don't CC)

Re: [PATCH 2/3] cxacru: Poll for device status more frequently.

[Duncan Sands]

> The device is only polled for status every 5 seconds yet status updates
> occur as often as every second - when the line is down the status changes
> between "down" and "attempting to activate" every 2 seconds.  

How much overhead does polling involve?  [A particularly problematic case
is when polling is failing - I've occasionally seen speedtouch modems
where polling fails every time (not sure why) and for some reason this
increases system load considerably, which is why the speedtch driver has
a dynamic polling interval].  If polling overhead is basically nothing,
then this change is OK with me.  Otherwise the next simplest thing to do
is to have a short polling interval when the line is down, and a longer
one when the line is up.

Ciao,

Duncan.

Re: [PATCH 2/3] cxacru: Poll for device status more frequently.

[Simon Arlott]

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

On 31/01/07 14:27, Duncan Sands wrote:
>> The device is only polled for status every 5 seconds yet status updates
>> occur as often as every second - when the line is down the status changes
>> between "down" and "attempting to activate" every 2 seconds.  
> 
> How much overhead does polling involve?  [A particularly problematic case
> is when polling is failing - I've occasionally seen speedtouch modems
> where polling fails every time (not sure why) and for some reason this
> increases system load considerably, which is why the speedtch driver has
> a dynamic polling interval].  If polling overhead is basically nothing,
> then this change is OK with me.  Otherwise the next simplest thing to do
> is to have a short polling interval when the line is down, and a longer
> one when the line is up.
> 

I've had it polling every 200ms on a dual ppro200 since november, and it has never failed to poll the status.


> Ciao,
> 
> Duncan.


-- 
Simon Arlott


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 829 bytes --]

Re: [PATCH 2/3] cxacru: Poll for device status more frequently.

[Duncan Sands]

> I've had it polling every 200ms on a dual ppro200 since november,
> and it has never failed to poll the status. 

Great, that's certainly better than the speedtouch ;)
I can't help feeling that polling twice a second is overkill.
How about changing it to poll every 5 seconds if the line is
up, and ten times as fast (as in this patch) if the line is
down?  Also, what is the point of polling fast?  Does it matter
if you miss some down-try_to_activate transitions?

Best wishes,

Duncan.

Re: [PATCH 2/3] cxacru: Poll for device status more frequently.

[Simon Arlott]

[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]

On 31/01/07 18:15, Duncan Sands wrote:
>> I've had it polling every 200ms on a dual ppro200 since november,
>> and it has never failed to poll the status. 
> 
> Great, that's certainly better than the speedtouch ;)
> I can't help feeling that polling twice a second is overkill.
> How about changing it to poll every 5 seconds if the line is
> up, and ten times as fast (as in this patch) if the line is
> down?  Also, what is the point of polling fast?  Does it matter
> if you miss some down-try_to_activate transitions?

It needs to be at most 2 seconds while down or it's going to miss some of the state changes, why bother to output all the types of state if you're going to ignore some of them?

As for while it's up, polling more often has a negligible effect on performance (still polling every 200ms here). If you change the timing for different states, you should know that it won't go into the down state on a retrain so ~up should enable faster polling.

-- 
Simon Arlott


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 829 bytes --]