Losing Packets!

I have a 1Mb line with Nildram and about 10 weeks ago started to get
intermittent poor performance.
I can be problem free for a number of days and then the problem re-occurs.

All internal connections, wiring (master socket is just 4 feet from line
entry point) and router have been eliminated.
I have been running ping and pathping tests supplied by Nildram and they
confirm intermittent packet loss.
BT have re-terminated the line which interestingly provided me with a 2Mb
connection!
Currently it has been lowered to 512kb and the problem still persists.
The investigation is ongoing!

Has anyone had a similar experience?
Any advice would be appreciated.

Chris

Chris Curtis wrote:
> I have a 1Mb line with Nildram and about 10 weeks ago started to get
> intermittent poor performance.
> I can be problem free for a number of days and then the problem re-occurs.
>
> All internal connections, wiring (master socket is just 4 feet from line
> entry point) and router have been eliminated.
> I have been running ping and pathping tests supplied by Nildram and they
> confirm intermittent packet loss.

What about router stats?

Ping shows IP packet loss. thats normally problem at the ISP's IP
router level.


You cannot be getting bad ADSL or you would likely be droppig the line.

Its eiher a congested backahul, or congetsed ISP internally.

Change ISPs to one that isn't so cheapskate.

> BT have re-terminated the line which interestingly provided me with a 2Mb
> connection!
> Currently it has been lowered to 512kb and the problem still persists.
> The investigation is ongoing!
>
> Has anyone had a similar experience?
> Any advice would be appreciated.
>
> Chris
>
>

"The Natural Philosopher" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Chris Curtis wrote:
>> I have a 1Mb line with Nildram and about 10 weeks ago started to get
>> intermittent poor performance.
>> I can be problem free for a number of days and then the problem
>> re-occurs.
>>
>> All internal connections, wiring (master socket is just 4 feet from line
>> entry point) and router have been eliminated.
>> I have been running ping and pathping tests supplied by Nildram and they
>> confirm intermittent packet loss.
>
> What about router stats?
>
> Ping shows IP packet loss. thats normally problem at the ISP's IP router
> level.
>
>
> You cannot be getting bad ADSL or you would likely be droppig the line.
>
> Its eiher a congested backahul, or congetsed ISP internally.
>
> Change ISPs to one that isn't so cheapskate.
>
>> BT have re-terminated the line which interestingly provided me with a 2Mb
>> connection!
>> Currently it has been lowered to 512kb and the problem still persists.
>> The investigation is ongoing!
>>
>> Has anyone had a similar experience?
>> Any advice would be appreciated.
>>
>> Chris
>>

Thanks for the reply.
I can confirm that the line doesn't drop when the packet loss is occuring.
I have two colleagues with Nildram who are connected to the same exchange as
me and they have been trouble free.

What sort of router stats are you referring to?

Chris

Chris Curtis wrote:
> "The Natural Philosopher" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Chris Curtis wrote:
>>> I have a 1Mb line with Nildram and about 10 weeks ago started to get
>>> intermittent poor performance.
>>> I can be problem free for a number of days and then the problem
>>> re-occurs.
>>>
>>> All internal connections, wiring (master socket is just 4 feet from line
>>> entry point) and router have been eliminated.
>>> I have been running ping and pathping tests supplied by Nildram and they
>>> confirm intermittent packet loss.
>> What about router stats?
>>
>> Ping shows IP packet loss. thats normally problem at the ISP's IP router
>> level.
>>
>>
>> You cannot be getting bad ADSL or you would likely be droppig the line.
>>
>> Its eiher a congested backahul, or congetsed ISP internally.
>>
>> Change ISPs to one that isn't so cheapskate.
>>
>>> BT have re-terminated the line which interestingly provided me with a 2Mb
>>> connection!
>>> Currently it has been lowered to 512kb and the problem still persists.
>>> The investigation is ongoing!
>>>
>>> Has anyone had a similar experience?
>>> Any advice would be appreciated.
>>>
>>> Chris
>>>
>
> Thanks for the reply.
> I can confirm that the line doesn't drop when the packet loss is occuring.

Ok..that sort of lets out bad line nose anyway.

> I have two colleagues with Nildram who are connected to the same exchange as
> me and they have been trouble free.

Thats is very weird..are they on the same level of service?

>
> What sort of router stats are you referring to?

There should be somewhere a load of stats like this..in my case its
under 'line quality' (D-link 504)

This block shows the basic operation mode.

Protocol ADSL
State Showtime
Data Path Interleave
Operation Mode G.DMT

This show the connection speeds, line losses and noise margins.

Downstream Upstream
Line Status
ADSL Link Speed 3872 kbps 448 kbps
SNR 7.5 dB 0.0 dB
ATEN 46 dB 25 dB

This shows he error rates since I last rebooted or reconnected.
Line Error
ADSL layer
FEC 22 1 ; you always get some of these.
CRC 0 0 ;these are not good to have a lot of, but should not cause
packet loss.

ATM layer HEC 0 0 ; These are probably very bad news..this is errors
in the backhaul to the ISP.

Frame Counter 477575 416954

Loop Distance: About 9 K ft.

I am getting the feeling it may be something in the IP layer itself.

This is using a MAC OSX shell to establish my upstream IP paths. Under
DOS/WIN the command is TRACERT instead..

traceroute www.bbc.co.uk
traceroute to www.bbc.net.uk (212.58.253.70), 64 hops max, 40 byte packets
1 192.168.0.254 (192.168.0.254) 2.443 ms 0.910 ms 0.784 ms
2 mod-rk-240.access.clara.net (195.8.68.240) 31.436 ms 32.509 ms
35.895 ms
3 t6-se1-ge-9-2-199.router.uk.clara.net (195.157.7.105) 28.926 ms
33.303 ms 34.091 ms
4 g1-1-7-t6-cr1.router.uk.clara.net (195.157.7.69) 30.735 ms 35.902
ms 37.619 ms
5 t6-br1-ge-2-0.router.uk.clara.net (195.8.86.206) 39.610 ms 29.367
ms 32.689 ms
6 claranet-gw.thdo.bbc.co.uk (195.8.86.202) 31.819 ms 31.957 ms
31.035 ms
7 212.58.238.129 (212.58.238.129) 29.061 ms 31.292 ms 30.089 ms
8 fe0-0.rt0-frontpost.prodgw.bbc.co.uk (212.58.239.222) 33.252 ms
31.707 ms 40.514 ms

That gives you a whole load of IP addresses to run pings against, moving
up the chain bit by bit , you can see which one is the problem. If it's
your own router you may have USB or inernal network issues, if its
further up it might be that your MTU is misconfigured.

I THINK for windows the command IPCONFIG shows a lot of useful stuff too.

I'll sing the praises of this site www.kitz.co.uk for having most of the
information on how DSL works explained very well. There are gaps, but I
have not come up with any errors.

See if you can dump some info here, and I'll try and puzzle through it.




>
> Chris
>
>

"The Natural Philosopher" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Chris Curtis wrote:
>> "The Natural Philosopher" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> Chris Curtis wrote:
>>>> I have a 1Mb line with Nildram and about 10 weeks ago started to get
>>>> intermittent poor performance.
>>>> I can be problem free for a number of days and then the problem
>>>> re-occurs.
>>>>
>>>> All internal connections, wiring (master socket is just 4 feet from
>>>> line entry point) and router have been eliminated.
>>>> I have been running ping and pathping tests supplied by Nildram and
>>>> they confirm intermittent packet loss.
>>> What about router stats?
>>>
>>> Ping shows IP packet loss. thats normally problem at the ISP's IP
>>> router level.
>>>
>>>
>>> You cannot be getting bad ADSL or you would likely be droppig the line.
>>>
>>> Its eiher a congested backahul, or congetsed ISP internally.
>>>
>>> Change ISPs to one that isn't so cheapskate.
>>>
>>>> BT have re-terminated the line which interestingly provided me with a
>>>> 2Mb connection!
>>>> Currently it has been lowered to 512kb and the problem still persists.
>>>> The investigation is ongoing!
>>>>
>>>> Has anyone had a similar experience?
>>>> Any advice would be appreciated.
>>>>
>>>> Chris
>>>>
>>
>> Thanks for the reply.
>> I can confirm that the line doesn't drop when the packet loss is
>> occuring.
>
> Ok..that sort of lets out bad line nose anyway.
>
>> I have two colleagues with Nildram who are connected to the same exchange
>> as me and they have been trouble free.
>
> Thats is very weird..are they on the same level of service?
>
>>
>> What sort of router stats are you referring to?
>
> There should be somewhere a load of stats like this..in my case its under
> 'line quality' (D-link 504)
>
> This block shows the basic operation mode.
>
> Protocol ADSL
> State Showtime
> Data Path Interleave
> Operation Mode G.DMT
>
> This show the connection speeds, line losses and noise margins.
>
> Downstream Upstream
> Line Status ADSL Link Speed 3872 kbps 448 kbps
> SNR 7.5 dB 0.0 dB
> ATEN 46 dB 25 dB
>
> This shows he error rates since I last rebooted or reconnected.
> Line Error ADSL layer FEC 22 1 ; you always get some of these.
> CRC 0 0 ;these are not good to have a lot of, but should not cause packet
> loss.
>
> ATM layer HEC 0 0 ; These are probably very bad news..this is errors in
> the backhaul to the ISP.
>
> Frame Counter 477575 416954
>
> Loop Distance: About 9 K ft.
>
> I am getting the feeling it may be something in the IP layer itself.
>
> This is using a MAC OSX shell to establish my upstream IP paths. Under
> DOS/WIN the command is TRACERT instead..
>
> traceroute www.bbc.co.uk
> traceroute to www.bbc.net.uk (212.58.253.70), 64 hops max, 40 byte packets
> 1 192.168.0.254 (192.168.0.254) 2.443 ms 0.910 ms 0.784 ms
> 2 mod-rk-240.access.clara.net (195.8.68.240) 31.436 ms 32.509 ms
> 35.895 ms
> 3 t6-se1-ge-9-2-199.router.uk.clara.net (195.157.7.105) 28.926 ms
> 33.303 ms 34.091 ms
> 4 g1-1-7-t6-cr1.router.uk.clara.net (195.157.7.69) 30.735 ms 35.902 ms
> 37.619 ms
> 5 t6-br1-ge-2-0.router.uk.clara.net (195.8.86.206) 39.610 ms 29.367 ms
> 32.689 ms
> 6 claranet-gw.thdo.bbc.co.uk (195.8.86.202) 31.819 ms 31.957 ms 31.035
> ms
> 7 212.58.238.129 (212.58.238.129) 29.061 ms 31.292 ms 30.089 ms
> 8 fe0-0.rt0-frontpost.prodgw.bbc.co.uk (212.58.239.222) 33.252 ms
> 31.707 ms 40.514 ms
>
> That gives you a whole load of IP addresses to run pings against, moving
> up the chain bit by bit , you can see which one is the problem. If it's
> your own router you may have USB or inernal network issues, if its further
> up it might be that your MTU is misconfigured.
>
> I THINK for windows the command IPCONFIG shows a lot of useful stuff too.
>
> I'll sing the praises of this site www.kitz.co.uk for having most of the
> information on how DSL works explained very well. There are gaps, but I
> have not come up with any errors.
>
> See if you can dump some info here, and I'll try and puzzle through it.
>
>
>
>
>>
>> Chris
>>

Some good info there. Thanks.
Yes my colleagues are on exactly the same service.

The Netgear DG834 diagnostics consist of pinging an ip address and
performing a dns lookup!
I've brought home a Creative router from the office which is pretty basic
but I think does have some better diagnostics.
I'll swap it over later but of course at the moment the line seems to be OK!

Here's a ping test I did when it was poor:
-------------------------------------------

Pinging 213.208.106.212 with 32 bytes of data:

Reply from 213.208.106.212: bytes=32 time=17ms TTL=59



Rep ly from 213.208.106.212: bytes=32 time=18ms TTL=59

Reply from 213.208.106.212: bytes=32 time=18ms TTL=59

Reply from 213.208.106.212: bytes=32 time=18ms TTL=59

Request timed out.

Request timed out.

Reply from 213.208.106.212: bytes=32 time=18ms TTL=59

Reply from 213.208.106.212: bytes=32 time=17ms TTL=59

Request timed out.

Reply from 213.208.106.212: bytes=32 time=19ms TTL=59

Request timed out.

Reply from 213.208.106.212: bytes=32 time=18ms TTL=59

Reply from 213.208.106.212: bytes=32 time=17ms TTL=59

Reply from 213.208.106.212: bytes=32 time=17ms TTL=59

Reply from 213.208.106.212: bytes=32 time=17ms TTL=59

Reply from 213.208.106.212: bytes=32 time=17ms TTL=59

Reply from 213.208.106.212: bytes=32 time=17ms TTL=59

Reply from 213.208.106.212: bytes=32 time=18ms TTL=59

Reply from 213.208.106.212: bytes=32 time=18ms TTL=59

Reply from 213.208.106.212: bytes=32 time=17ms TTL=59

Reply from 213.208.106.212: bytes=32 time=18ms TTL=59

Reply from 213.208.106.212: bytes=32 time=18ms TTL=59

Reply from 213.208.106.212: bytes=32 time=17ms TTL=59

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Reply from 213.208.106.212: bytes=32 time=17ms TTL=59

Reply from 213.208.106.212: bytes=32 time=17ms TTL=59

Request timed out.

Request timed out.

Reply from 213.208.106.212: bytes=32 time=17ms TTL=59

Reply from 213.208.106.212: bytes=32 time=16ms TTL=59

Reply from 213.208.106.212: bytes=32 time=17ms TTL=59

Reply from 213.208.106.212: bytes=32 time=16ms TTL=59

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Reply from 213.208.106.212: bytes=32 time=17ms TTL=59

Reply from 213.208.106.212: bytes=32 time=17ms TTL=59

Reply from 213.208.106.212: bytes=32 time=16ms TTL=59

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Reply from 213.208.106.212: bytes=32 time=17ms TTL=59

Reply from 213.208.106.212: bytes=32 time=17ms TTL=59

Reply from 213.208.106.212: bytes=32 time=18ms TTL=59

Request timed out.

Request timed out.

Reply from 213.208.106.212: bytes=32 time=17ms TTL=59

Reply from 213.208.106.212: bytes=32 time=16ms TTL=59

Reply from 213.208.106.212: bytes=32 time=16ms TTL=59

Request timed out.

Request timed out.

Reply from 213.208.106.212: bytes=32 time=18ms TTL=59

Reply from 213.208.106.212: bytes=32 time=18ms TTL=59

Request timed out.

Request timed out.

Reply from 213.208.106.212: bytes=32 time=16ms TTL=59

Reply from 213.208.106.212: bytes=32 time=17ms TTL=59

Reply from 213.208.106.212: bytes=32 time=17ms TTL=59

Request timed out.

Request timed out.

Reply from 213.208.106.212: bytes=32 time=16ms TTL=59

Reply from 213.208.106.212: bytes=32 time=16ms TTL=59

Reply from 213.208.106.212: bytes=32 time=18ms TTL=59

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Reply from 213.208.106.212: bytes=32 time=16ms TTL=59

Request timed out.

Request timed out.

Reply from 213.208.106.212: bytes=32 time=18ms TTL=59

Request timed out.

Reply from 213.208.106.212: bytes=32 time=17ms TTL=59

Reply from 213.208.106.212: bytes=32 time=17ms TTL=59

Reply from 213.208.106.212: bytes=32 time=17ms TTL=59

Reply from 213.208.106.212: bytes=32 time=17ms TTL=59

Reply from 213.208.106.212: bytes=32 time=17ms TTL=59

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Reply from 213.208.106.212: bytes=32 time=18ms TTL=59

Request timed out.

Request timed out.

Reply from 213.208.106.212: bytes=32 time=17ms TTL=59

Reply from 213.208.106.212: bytes=32 time=17ms TTL=59

Reply from 213.208.106.212: bytes=32 time=16ms TTL=59

Request timed out.

Request timed out.

Request timed out.

Reply from 213.208.106.212: bytes=32 time=18ms TTL=59

Reply from 213.208.106.212: bytes=32 time=18ms TTL=59



Ping statistics for 213.208.106.212:

Packets: Sent = 100, Received = 55, Lost = 45 (45% loss),

Approximate round trip times in milli-seconds:

Minimum = 16ms, Maximum = 19ms, Average = 17ms

------------------------------------------------------------

And a tracert at the same time:



Tracing route to 213.208.106.212 over a maximum of 30 hops



0 chrishome [192.168.0.2]

1 www.routerlogin.com [192.168.0.1]

2 62.241.167.207

3 * * *

Computing statistics for 75 seconds...

Source to Here This Node/Link

Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address

0 chrishome [192.168.0.2]

0/ 100 = 0% |

1 0ms 0/ 100 = 0% 0/ 100 = 0% www.routerlogin.com
[192.168.0.1]

72/ 100 = 72% |

2 19ms 72/ 100 = 72% 0/ 100 = 0% 62.241.167.207

28/ 100 = 28% |

3 --- 100/ 100 =100% 0/ 100 = 0% chrishome [0.0.0.0]



Trace complete.

---------------------------------------------------------------



These were when it was unusable and ping requests to the BBC and ITV were
unable to connect!

I'll swap the routers now and post back some diagnostics!



Chris

OK I've set the Creative router up; the diagnostics (such as they are!):

Checking LAN Connection
Testing Ethernet LAN connection PASS HELP
Checking ADSL Connection
Testing ADSL Synchronization PASS HELP
Checking Circuit 0 for Network Connection
Test ATM OAM Segment Loop Back FAIL HELP
Test ATM OAM End-to-End Loop Back FAIL HELP
Test Ethernet connect to ATM PASS HELP
Test PPPoPvc 0 PPPOE connection UNKNOWN HELP
Test PPPoPvc 0 PPP layer connection PASS HELP
Test PPPoPvc 0 IP connect to PPP PASS HELP
Testing Internet Connection
Ping default gateway 62.241.167.207 PASS HELP


--------------------------------------------------------------------------
ADSL Line Status: SHOWTIME
Downstream Data Rate: 576kbps
Upstream Data Rate: 256kbps

PPP Connection Status: Connected
Protocol & Encapsulation Mode: PPPoA VC-Mux
VPI/VCI: 0/38


------------------------------------------------------------------------------
# Connection Name Interface Mode Status Pkts Sent Pkts Revd Bytes Sent
Bytes Rcvd
1 PPPoPvc 0 Pvc 0 PPPoA Connected 279 331 31966 158235

If a * appears under Mode column, you need to check the WAN configuration to
make sure the VC has the correct encapsulation.

Incidentally when I'm having problems, the packet loss is usually between 5%
and 20%.

Hope this is OK!

Regards
Chris

On 19-Nov-2007, The Natural Philosopher <(E-Mail Removed)> wrote:

> >>> I have a 1Mb line with Nildram and about 10 weeks ago started to get
> >>> intermittent poor performance.
> >>> I can be problem free for a number of days and then the problem
> >>> re-occurs.

Some intermittent issues are time of day sensitive, 7pm - 11pm problems,
3am - 4am no problems.
Some days fine, others not.

Chris Curtis wrote:
> OK I've set the Creative router up; the diagnostics (such as they are!):
>
> Checking LAN Connection
> Testing Ethernet LAN connection PASS HELP
> Checking ADSL Connection
> Testing ADSL Synchronization PASS HELP
> Checking Circuit 0 for Network Connection
> Test ATM OAM Segment Loop Back FAIL HELP
> Test ATM OAM End-to-End Loop Back FAIL HELP

Ok those are a problem. The BT ATM stuff is kaput.

Thats is WEIRD as its the same circuit your friends are using.

Report this to your ISP but do not expect a rapid fix.

> Test Ethernet connect to ATM PASS HELP
> Test PPPoPvc 0 PPPOE connection UNKNOWN HELP
> Test PPPoPvc 0 PPP layer connection PASS HELP
> Test PPPoPvc 0 IP connect to PPP PASS HELP
> Testing Internet Connection
> Ping default gateway 62.241.167.207 PASS HELP
>
>

However its odd you DO get a ppp connection with a failed ATM test.
Curiouser and curiouser. Must be a flakey ATM.


BT report one extant issue on dial code 01807

http://www.btbroadbandoffice.com/bus...B_Home,00.html


Also check here to see if its a known problem
http://usertools.plus.net/exchanges/mso.php

> --------------------------------------------------------------------------
> ADSL Line Status: SHOWTIME
> Downstream Data Rate: 576kbps
> Upstream Data Rate: 256kbps
>
> PPP Connection Status: Connected
> Protocol & Encapsulation Mode: PPPoA VC-Mux
> VPI/VCI: 0/38
>
>
> ------------------------------------------------------------------------------
> # Connection Name Interface Mode Status Pkts Sent Pkts Revd Bytes Sent
> Bytes Rcvd
> 1 PPPoPvc 0 Pvc 0 PPPoA Connected 279 331 31966 158235
>
> If a * appears under Mode column, you need to check the WAN configuration to
> make sure the VC has the correct encapsulation.
>
> Incidentally when I'm having problems, the packet loss is usually between 5%
> and 20%.
>
> Hope this is OK!
>
> Regards
> Chris
>
>
>
>

"The Natural Philosopher" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Chris Curtis wrote:
>> OK I've set the Creative router up; the diagnostics (such as they are!):
>>
>> Checking LAN Connection
>> Testing Ethernet LAN connection PASS HELP
>> Checking ADSL Connection
>> Testing ADSL Synchronization PASS HELP
>> Checking Circuit 0 for Network Connection
>> Test ATM OAM Segment Loop Back FAIL HELP
>> Test ATM OAM End-to-End Loop Back FAIL HELP
>
> Ok those are a problem. The BT ATM stuff is kaput.
>
> Thats is WEIRD as its the same circuit your friends are using.
>
> Report this to your ISP but do not expect a rapid fix.
>
>> Test Ethernet connect to ATM PASS HELP
>> Test PPPoPvc 0 PPPOE connection UNKNOWN HELP
>> Test PPPoPvc 0 PPP layer connection PASS HELP
>> Test PPPoPvc 0 IP connect to PPP PASS HELP
>> Testing Internet Connection
>> Ping default gateway 62.241.167.207 PASS HELP
>>
>>
>
> However its odd you DO get a ppp connection with a failed ATM test.
> Curiouser and curiouser. Must be a flakey ATM.
>
>
> BT report one extant issue on dial code 01807
>
> http://www.btbroadbandoffice.com/bus...B_Home,00.html
>
>
> Also check here to see if its a known problem
> http://usertools.plus.net/exchanges/mso.php
>
>> --------------------------------------------------------------------------
>> ADSL Line Status: SHOWTIME
>> Downstream Data Rate: 576kbps
>> Upstream Data Rate: 256kbps
>>
>> PPP Connection Status: Connected
>> Protocol & Encapsulation Mode: PPPoA VC-Mux
>> VPI/VCI: 0/38
>>
>>
>> ------------------------------------------------------------------------------
>> # Connection Name Interface Mode Status Pkts Sent Pkts Revd Bytes
>> Sent Bytes Rcvd
>> 1 PPPoPvc 0 Pvc 0 PPPoA Connected 279 331 31966 158235
>>
>> If a * appears under Mode column, you need to check the WAN configuration
>> to make sure the VC has the correct encapsulation.
>>
>> Incidentally when I'm having problems, the packet loss is usually between
>> 5% and 20%.
>>
>> Hope this is OK!
>>
>> Regards
>> Chris
>>

OK thanks for that.
I'll forward them to Nildram and ask them to investigate.

Chris

<(E-Mail Removed)> wrote in message
news:4741fc27$0$8428$(E-Mail Removed)...
>
> On 19-Nov-2007, The Natural Philosopher <(E-Mail Removed)> wrote:
>
>> >>> I have a 1Mb line with Nildram and about 10 weeks ago started to get
>> >>> intermittent poor performance.
>> >>> I can be problem free for a number of days and then the problem
>> >>> re-occurs.
>
> Some intermittent issues are time of day sensitive, 7pm - 11pm problems,
> 3am - 4am no problems.
> Some days fine, others not.

The isp have been monitoring during the night and found no real difference.
I went practically a whole week without any interruption 3 weeks ago!

Chris