Frequent "hickups"

[camh]

I've been experiencing HDPA "hickups" for the last few months. These hickups are pauses where I get no data for 15-20 seconds, sometimes less, sometimes more. The PPP session does not drop out, nor do I need to do anything to reestablish dataflow.

I often use my HSPA connection to ssh into my machine(s) at home. To make this usable, I need to keep a ping running in the background to keep it running at HSDPA speeds, and not falling back to WCDMA. I do this because the round trip latency on WCDMA is about 500ms which is too high to use an interactive session. I have a ping interval of 1.2 seconds.

Here's an example of the ping output when a hickup occurs:

Code: Select all

64 bytes from 220.233.XXX.XXX: icmp_seq=48 ttl=63 time=156 ms
64 bytes from 220.233.XXX.XXX: icmp_seq=49 ttl=63 time=154 ms
64 bytes from 220.233.XXX.XXX: icmp_seq=50 ttl=63 time=163 ms
64 bytes from 220.233.XXX.XXX: icmp_seq=51 ttl=63 time=161 ms
64 bytes from 220.233.XXX.XXX: icmp_seq=52 ttl=63 time=8252 ms
64 bytes from 220.233.XXX.XXX: icmp_seq=53 ttl=63 time=7119 ms
64 bytes from 220.233.XXX.XXX: icmp_seq=54 ttl=63 time=5910 ms
64 bytes from 220.233.XXX.XXX: icmp_seq=55 ttl=63 time=4711 ms
64 bytes from 220.233.XXX.XXX: icmp_seq=56 ttl=63 time=3512 ms
64 bytes from 220.233.XXX.XXX: icmp_seq=57 ttl=63 time=2302 ms
64 bytes from 220.233.XXX.XXX: icmp_seq=58 ttl=63 time=1099 ms
64 bytes from 220.233.XXX.XXX: icmp_seq=59 ttl=63 time=149 ms
64 bytes from 220.233.XXX.XXX: icmp_seq=60 ttl=63 time=168 ms

You can see that no packets are lost, but seq #52 is delayed by about 8 seconds. Most of the time there is no packet loss. I haven't run a network trace on the other end yet to see if the problem is in the uplink or downlink, but I can if necessary.

The pattern is quite variable. At the moment, I am getting about 1 hickup a minute for about 6 seconds or so each hickup. Other times it is much worse with continual 20 second hickups.

I am using an E169 on a linux netbook, from South Melbourne, during business hours.

I suspect there must be something wrong that can be fixed, since it is meant to be possible to do VoIP over HSPA, but with the hickups I'm getting, there's no way you'd get acceptable calls.

Is there something I can do at my end, or should I just raise a ticket?

[camh]

"Stall" would be a better word to use than hickup, but I couldn't think of it when writing the above message.

Possibly the same problem as reported in: http://forum.exetel.com.au/viewtopic.php?f=54&t=32288 (slow 3g and stalls)

[JasonM]

Is it OK when browsing?
If so, I think you can enable an option in PuTTY which will allow a continuous send of ACK packets, which will keep the connection established and in HSDPA mode, but this will also add to the data consumption.
If you are able to, testing a call might help determine if the above is correct (it's falling back to WCDMA).

It's also possible it's falling back to GSM, however, using a Linux Netbook means you aren't using the supported software, however, if you can find out how to change the network to WCDMA 2100 Only, you might see it perform better (this is an option provided for in the Windows / Mac software).

[camh]

Is it OK when browsing?

No. The stalls happen then as well, although I dont do much browsing over this connection.

If so, I think you can enable an option in PuTTY which will allow a continuous send of ACK packets, which will keep the connection established and in HSDPA mode, but this will also add to the data consumption.
If you are able to, testing a call might help determine if the above is correct (it's falling back to WCDMA).

??? I thought I explained my testing methodology, which covers this ???
I have a continuous stream of pings running in the background. I use that to lock it into HSDPA mode (cyan-coloured light) so it does not fall back to WCDMA mode (dark blue-coloured light). This is what I explained in my original post. Whether it is ssh sending keep-alives or a ping, it really shouldn't matter. It's just data packets keeping the HDSPA (cyan) mode active.

When the stall occurs, it will fall back to WCDMA (dark blue), but this is expected since there is no data flowing. If I stop the ping and cease other activity, it will also fall back to WCDMA.

It's also possible it's falling back to GSM, however, using a Linux Netbook means you aren't using the supported software, however, if you can find out how to change the network to WCDMA 2100 Only, you might see it perform better (this is an option provided for in the Windows / Mac software).

It is not falling back to GSM/GPRS (green light). I also cannot use WCDMA (dark blue) since the latency makes the connection unusable for interactive sessions. So I would not want to lock to WCDMA.

However, the problem is not a bandwidth issue - I dont need better performance in that regard. I would like to stop the stalls that are occurring regularly.

Should I raise a ticket for this?

[JasonM]

Is there any possibility of testing with the windows based software, to see if it's swapping between the different modes, or the signal coverage is being lost?
Is this location specific?

The 'stalls' are likely to be coverage related, or the modem is losing coverage, or swapping to a different mode, and then reestablishing the connection (resulting in no data flow).

[camh]

Is there any possibility of testing with the windows based software, to see if it's swapping between the different modes, or the signal coverage is being lost?

No possibility of Windows. I don't use it anywhere. If you know the AT commands to get the info you need, I can issue them.

If the mode changes, doesn't the colour of the LED change? GPRS - green, WCDMA - blue, HSDPA - cyan. These are the colours described in the manual. Based on this, the mode changes as described in my previous message. I have never seen the modem operate in GPRS mode in the time I have had it (6 months).

But even if it changes mode, should it stall for 20 seconds? I've had some stalls as long as 90 seconds.

Is this location specific?

I mostly use it on my desk at work during the day. It doesn't move, so I dont know if the signal would be dropping out in this scenario.

I do use it on the tram on the way in to work and have had the occassional stall, but it is much worse at work in South Melbourne.

The 'stalls' are likely to be coverage related, or the modem is losing coverage, or swapping to a different mode, and then reestablishing the connection (resulting in no data flow).

The netbook sits immobile on my desk as this happens. Given this, it is likely to be a loss of coverage?

[Dazzled]

camh, you might be just the person to test something potentially useful. The code at http://oozie.fm.interia.pl/pro/huawei-e220/ reads the usb port (with an e220 in it) and formats the output on an ncurses display. Does it work on the e169? That is, is there no change in format? (I don't have a 169 at hand at the moment)

[camh]

camh, you might be just the person to test something potentially useful.

I had to change it to use /dev/ttyUSB2, but it seems to work fine for the E169.

It doesn't seem to show anything useful though:

Code: Select all

              Uptime  : 31858s
              SpeedUp : 0kB/s
   (no data)  SpeedDn : 0kB/s
              Trnsfd  : 3.0MB
              Recvd   : 7.7MB

   STRENGTH   Mode: WCDMA

The mode status just mirrors the LED on the usb stick, and the other data can be obtained from the ppp0 interface.

I'll keep it running for a while and see if it shows anything else that might be useful.

[Dazzled]

Thanks for that test. The raw output must be what the Windows app sees, so there should be useful info in there somewhere. So far as I can see Huawei won't make the output spec publicly available. Did your output get the signal strength bars (no data)?

[camh]

No signal strength. It looks like I'm not getting any ^RSSI: lines from /dev/ttyUSB2. I tried stopping and starting the connection, but I still didn't get any strength info.

There is probably an AT command to retrieve it. In that case you'd send it on ttyUSB1, but I dont know what the command is. I'll do some research tonight.

[camh]

No signal strength. It looks like I'm not getting any ^RSSI: lines from /dev/ttyUSB2.

I stand corrected. I just got a couple of RSSI lines by putting my hand over the modem. This reduced the signal strength and I saw it come through.

Signal strength is good (excellent?):

Code: Select all

          |   Uptime  : 662s
        |||   SpeedUp : 0kB/s
      |||||   SpeedDn : 0kB/s
    |||||||   Trnsfd  : 0.0MB
  |||||||||   Recvd   : 0.1MB

   STRENGTH   Mode: WCDMA

[Dazzled]

http://lars-bamberger.gmxhome.de/linux/E169.html seems to have looked at AT commands

Edit: Thanks for the test - I will try it myself when I get the modem again. Another thread had a call for an Ubuntu signal strength indicator, and I suggested this one, until some more work is done on Modem Manager.

PS This bloke has had a look too (with code) - http://www.mavetju.org/weblog/html/cat_Huawei_E169.html

[camh]

The 'stalls' are likely to be coverage related, or the modem is losing coverage, or swapping to a different mode, and then reestablishing the connection (resulting in no data flow).

Using the tool that Dazzled pointed me to, I can say now that when this stall occurs, there is no change in signal strength.

I also did a few tests to see what the impact of changing modes was, and when things are working well, a mode change from HSDPA to WCDMA or the other way incurs a stall of about 1-2 seconds.

Would a stall of 15-20 seconds be expected for a mode change?

[JasonM]

No, it shouldn't.

When the issue happens, the computer doesn't indicate it is losing contact with the modem for example?

Testing with a supported operating system might reveal the same results, and if so - we can then escalate to our supplier.

[Dazzled]

You could try usbmon to keep track. The original author's java version is at http://www.lrr.in.tum.de/Par/arch/usb/linux-usb/USBMon/ It is kernel and JRE version dependent, so may need some fiddles. Some distros have got it.

PS There is a description of intercepting the kernel at http://www.mjmwired.net/kernel/Document ... usbmon.txt