File sync speed, reliability

To those who are already using CC, how is the speed and uptime of the file syncing service? I tried it free in the browser (I think they give 2 GB free) and the speed seemed glacially slow compared to services like DropBox. Also, my InDesign file synced but it doesn't show your linked images so everything is a low-res preview. Worse than a PDF. I'm trying to understand how I would ever use this to show something to a client.

Bill Bridgeforth wrote:
How is the speed and uptime of the file syncing service?
Hi Bill,
There is this:
http://status.creativecloud.com/
Judging by daily things like:
- Sync is down (completely, like the last few days)
- Some users may experience delays in working with their files.
- Some users may experience poor performance with some features of the service.
It seems pretty self evident this is not a viable option for professionals or those who need a reliable service.

Similar Messages

Log file sync question

Metalink note 34592.1 has been mentioned several times in this forum as well as elsewhere, notably here
http://christianbilien.wordpress.com/2008/02/12/the-%E2%80%9Clog-file-sync%E2%80%9D-wait-event-is-not-always-spent-waiting-for-an-io/
The question I have relates to the stated breakdown of 'log file sync' wait event:
1. Wakeup LGWR if idle
2. LGWR gathers the redo to be written and issue the I/O
3. Time for the log write I/O to complete
4. LGWR I/O post processing
5. LGWR posting the foreground/user session that the write has completed
6. Foreground/user session wakeup
Since the note says that the system 'read write' statistic includes steps 2 and 3, the suggestion is that the difference between it and 'log file sync' is due to CPU related work on steps 1, 4, 5 and 6 (or on waiting on the CPU run queue).
Christian's article, quoted above, theorises about 'CPU storms' and the Metalink note also suggests that steps 5 and 6 could be costly.
However, my understanding of how LGWR works is that if it is already in the process of writing out one set of blocks (let us say associated with a commit of transaction 'X' amongst others) at the time a another transaction (call it transaction 'Y') commits, then LGWR will not commence the write of the commit for transaction 'Y' until the I/Os associated with the commit of transaction 'X' complete.
So, if I have an average 'redo write' time of, say, 12ms and a 'log file sync' time of, say 34ms (yes, of course these are real numbers :-)) then I would have thought that this 22ms delay was due at least partly to LGWR 'falling behind' in it's work.
Nonetheless, it seems to me that this extra delay could only be a maximum of 12ms so this still leaves 10ms (34 - 12 -12) that can only be accounted for by CPU usage.
Clearly, my analsys contains a lot of conjecture, hence this note.
Can anybody point me in the direction of some facts?

Tony Hasler wrote:
Metalink note 34592.1 has been mentioned several times in this forum as well as elsewhere, notably here
http://christianbilien.wordpress.com/2008/02/12/the-%E2%80%9Clog-file-sync%E2%80%9D-wait-event-is-not-always-spent-waiting-for-an-io/
The question I have relates to the stated breakdown of 'log file sync' wait event:
1. Wakeup LGWR if idle
2. LGWR gathers the redo to be written and issue the I/O
3. Time for the log write I/O to complete
4. LGWR I/O post processing
5. LGWR posting the foreground/user session that the write has completed
6. Foreground/user session wakeup
Since the note says that the system 'read write' statistic includes steps 2 and 3, the suggestion is that the difference between it and 'log file sync' is due to CPU related work on steps 1, 4, 5 and 6 (or on waiting on the CPU run queue).
Christian's article, quoted above, theorises about 'CPU storms' and the Metalink note also suggests that steps 5 and 6 could be costly.
However, my understanding of how LGWR works is that if it is already in the process of writing out one set of blocks (let us say associated with a commit of transaction 'X' amongst others) at the time a another transaction (call it transaction 'Y') commits, then LGWR will not commence the write of the commit for transaction 'Y' until the I/Os associated with the commit of transaction 'X' complete.
So, if I have an average 'redo write' time of, say, 12ms and a 'log file sync' time of, say 34ms (yes, of course these are real numbers :-)) then I would have thought that this 22ms delay was due at least partly to LGWR 'falling behind' in it's work.
Nonetheless, it seems to me that this extra delay could only be a maximum of 12ms so this still leaves 10ms (34 - 12 -12) that can only be accounted for by CPU usage.
Clearly, my analsys contains a lot of conjecture, hence this note.
Can anybody point me in the direction of some facts?It depends on what you mean by facts - presumably only the people who wrote the code know what really happens, the rest of us have to guess.
You're right about point 1 in the MOS note: it should include "or wait for current lgwr write and posts to complete".
This means, of course, that your session could see its "log file sync" taking twice the "redo write time" because it posted lgwr just after lgwr has started to write - so you have to wait two write and post cycles. Generally the statistical effects will reduce this extreme case.
You've been pointed to the two best bits of advice on the internet: As Kevin points out, if you have lgwr posting a lot of processes in one go it may stall as they wake up, so the batch of waiting processes has to wait extra time; and as Riyaj points out - there's always dtrace (et al.) if you want to see what's really happening. (Tanel has some similar notes, I think, on LFS).
If you're stuck with Oracle diagnostics only then:
redo size / redo synch writes for sessions will tell you the typical "commit size"
redo size + redo wastage / redo writes for lgwr will tell you the typical redo write size
If you have a significant number of small processes "commit sizes" per write (more than CPU count, say) then you may be looking at Kevin's storm.
Watch out for a small number of sessions with large commit sizes running in parallel with a large number of sessions with small commit sizes - this could make all the "small" processes run at the speed of the "large" processes.
It's always worth looking at the event histogram for the critical wait events to see if their patterns offer any insights.
Regards
Jonathan Lewis

I can't get the Business Catalyst add on to work due to file sync not working

I'm trying to create a new Business Catalyst site via Dreamweaver. I installed the add-on in creative cloud, restarted my machine and Dreamweaver. I realised that in Creative Cloud preferences file sync was turned off, so I turned it on and restarted my machine and found that in preferences it was turned off again. I need to know why it won't save this setting.

Are you running LabVIEW 7.0? The 7.1 version seems to work reliably but the 7.0 version does not to seem to work most of the time. I am having the same problems as you describe. Must be some bug in 7.0, but I have not had time to compare the code. Anyone?
LabVIEW Champion . Do more with less code and in less time .

Automatic File Sync aka "use it and forget it"

Is it possible to invoke File Sync in a non-interactive way. I want file syncing to be automatic and done "under the covers" for one of our user groups. Failing that, is there any APIs that could be used to build some custom code?
John Oakley

The Auto Tool rocks. I admit it takes some getting used to. And I definitely turn off the Auto Tool locking feature in Tools > Options (in case I do need to Tab or Space). In the rare circumstance where I need some tool behavior that the Auto Tool doesn't readily provide, I just shift-right click to bring up the Tools palettes and just keep going. Plus, the auto tool seems to get a little smarter with each LabVIEW release.
And just so y'all don't think I'm biased, there are NI people who disagree...one of my teammates, in fact, who is an old-school LabVIEW guy, hates the Auto Tool and has never switched to using it. But whenever I occasionally need to use an older, pre-autotool version of LabVIEW for whatever reason, I feel totally crippled having to Tab/Space every time I need a new tool.
You should find that after you get used to it, the Auto Tool speeds up your LabVIEW programming tremendously.
-D
Message Edited by Darren on 03-15-2006 05:17 PM
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

Log File Sync

Hi all, I am using Oracle 10gR2 on Solaris 10.
It did a SQL Trace and came up with the following resultMisses in library cache during parse: 591
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
library cache lock                            241        0.06          0.61
KJC: Wait for msg sends to complete             2        0.00          0.00
SQL*Net message to client                    1768        0.00          0.00
SQL*Net message from client                  1768        0.14          7.94
row cache lock                                  7        0.00          0.00
gc cr grant 2-way                               1        0.00          0.00
db file sequential read                        67        0.87          6.73
gc current grant 2-way                         19        0.00          0.01
gc current grant busy                          58        0.01          0.08
log file sync                                3055        0.98       2592.00
gc current block 2-way                         14        0.00          0.02
gc cr block 2-way                              77        0.00          0.06
log file switch completion                     12        0.98          8.80
gc current request                              5        1.23          6.15
gc current block lost                           1        0.45          0.45
lock deadlock retry                             1        0.00          0.00
latch free                                      1        0.00          0.00
enq: TM - contention                            1        0.00          0.00
gc cr request                                   5        1.23          6.14
gc cr block lost                                1        0.31          0.31
cr request retry                                1        0.00          0.00
latch: session allocation                       1        0.00          0.00
gc buffer busy                                  2        0.98          1.96
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse      237      0.08       0.05          0          0         38           0
Execute   2184      0.51       6.17          1        200        585         364
Fetch     1884      0.18       6.96         27       3234        195        2127
total     4305      0.77      13.19         28       3434        818        2491
Misses in library cache during parse: 21
Misses in library cache during execute: 19
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
library cache lock                             21        0.00          0.01
row cache lock                                248        0.01          0.08
gc cr grant 2-way                               3        0.00          0.00
db file sequential read                        28        1.01          3.22
gc current grant busy                           8        0.00          0.00
gc current block 2-way                          5        0.00          0.00
gc cr block 2-way                               1        0.00          0.00
log file switch completion                      4        0.98          3.55
gc current request                              1        1.22          1.22
latch: KCL gc element parent latch              1        0.00          0.00
latch: redo allocation                          1        0.00          0.00
gc current block busy                           1        0.64          0.64
1181 user SQL statements in session.
314 internal SQL statements in session.
1495 SQL statements in session.There is a lot of log file sync waits. There were a lot of INSERTS in the sql but I did not find any commits. For example
INSERT INTO CM_WORKFLOW_AUDIT (AUDIT_TRAIL_ID, CASE_HISTORY_ID,USER_ID,
GROUP_ID,ACTION_ID,DESCRIPTION,DATE_TIME)
VALUES
('080504001809',2154515,19,2,23,'Ticket[2157817] added to Super Ticket',
TO_DATE('04-05-2008 13:14:38','dd-mm-yyyy HH24:MI:SS'))
But there is no commit at the end, there are a lot of INSERTS like this one but no commit at the end of it. So log file sync cant be waiting to flush the buffer into a redolog (well, that is what I think atleast). Can some one please tell me what is causing the log files sync wait? By the way my log_buffer is 12mb.
Regards.....

Hi,
The number of commits can be retrieved from v$sysstat and v$sesstat.
There are no commit statements in any trace file,
you need to look at lines starting with XCTEND in the raw trace data.
Also the size of the log_buffer has 0 to do with the log file sync event, and setting big log_buffer is the typical 'more is better' tuning which doesn't help.
You need to investigate the speed of the devices with holding online redolog, do NOT locate online redologs on RAID-5 devices.
Also posting 'Any one ??' when you are not getting response immediately shows you don't seem to understand this is a volunteer forum.
Sybrand Bakker
Senior Oracle DBA

Log file sync spike

We have just deployed a 4-node RAC cluster on 10GR2. We force a log switch every 5 minutes to ensure our Dataguard standby site is relatively up to date, we use the ARCH to ship logs. We are running to a very fast HP XP 12000 with massive amounts of write cache, so we never actually write straight to disk. However everytime we do a log switch and archive the log, we see a massive spike in the log file sync event. This is a real-time billing system so we monitor transaction response times in ms. Our response time for a transaction can go from 8ms to around 500ms.
I can't understand why this is happening, not only are our disks fast but we are also using asynch I/O and ASM. Surely with asynch I/O you should never wait for a write to complete.

Log file sync event happens when client wait for LGWR finishes write to the log file after client said 'commit'. The way to reduce the number of the 'Log file sync' events is to increase the speed of LGWR process or not to commit that often.
You've described your disk system as very fast - what is the amount of data you write on every log switch? How does the performance of this write relates to your disk system tests? what block size did you use when testing the disk system? as far as I remember the LGWR uses OS block size and not the DB block size to write data to the disk. Try to experiment on your test system - put your log files on the virtual disk created in RAM and run the test case - do you see the delays?
With such restrictions for the transaction time you may want to look at Oracle Times-Ten database (http://www.oracle.com/database/timesten.html)
Since you've mentioned the 10gR2 you could probably use the new feature - asynchronous commit - in this case your transaction will not wait for the LGWR process. Be aware that using the NOWAIT commit opens a small possibility of data loss - the doc describes it quite clear.
http://download-east.oracle.com/docs/cd/B19306_01/appdev.102/b14251/adfns_sqlproc.htm#CIHEDGBF
Mike

Log file sync wait event advise?

Due to business needs, Apps has been designed to do every single transaction commit and coming to infrastructure, db Datafiles and redo logs are in faster disk (FC) and archive logs are placed in slower speed disk(SATA). We are seeing the log file sync wait event in the top events and symptoms for this waitevent is either disk speed is slow or doing frequent commit. In my scenario i guess 99% this wait event happening due to frequent commits. Can i assume archive log slower disk will not be root cause for this (my understanding this waitevent occurs on redo log writing area and not in archive log writing area) ? Please confirm.

user530956 wrote:
We are seeing the log file sync wait event in the top events and symptoms for this waitevent is either disk speed is slow or doing frequent commit.As Hemant has pointed out, this could also be due to CPU overload.
I note you say the event is IN the top events - this tells us virtually nothing; an event might be IN the top 5 while being responsible for less than 1% of the total recorded wait time; it could be IN the top 5 but explained as a side effect of something that appeared above it in the Top 5. Why not just show us a typical Top 5 (along with a typical Load Profile it you want to be really helpful).
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files from text files, START and END the text with the tag {noformat}{noformat} (the word "code" in lowercase, curly brackets, no spaces) so that the text appears in fixed format. This won't be sufficient if you try to cut and paste from an HTML report, which will need further editing.

High waits on log file sync

Dear Experts,
There is a huge wait on log file sync. I have 5 redo log groups 3 members each. I suspect writing to one group which is hosted on /proddb is taking time. Is there a way we can identify and control this.
DB is on 10.2.0.4
OS is RHEL 5
    GROUP# STATUS TYPE    MEMBER
         1         ONLINE /proddb/proddata/log01a.dbf
         1         ONLINE /proddb/proddata/log01b.dbf
         1         ONLINE /prodlog/proddata/log01c.dbf
         2         ONLINE /proddb/proddata/log02a.dbf
         2         ONLINE /proddb/proddata/log02b.dbf
         2         ONLINE /prodlog/proddata/log02c.dbf
         3         ONLINE /proddb/proddata/log03a.dbf
         3         ONLINE /proddb/proddata/log03b.dbf
         3         ONLINE /prodlog/proddata/log03c.dbf
         4         ONLINE /proddb/proddata/log04a.dbf
         4         ONLINE /proddb/proddata/log04b.dbf
    GROUP# STATUS TYPE    MEMBER
         4         ONLINE /prodlog/proddata/log04c.dbf
         5         ONLINE /proddb/proddata/log05a.dbf
         5         ONLINE /proddb/proddata/log05b.dbf
         5         ONLINE /prodlog/proddata/log05c.dbfEach log file member is 300MB in size and log buffer is 14MB
Thanks
Neel

>
There is a huge wait on log file sync. I have 5 redo log groups 3 members each. I suspect writing to one group which is hosted on /proddb is taking time. Is there a way we can identify and control this.
>
Log file sync is a client wait basically. The only way to control this is by not committing too frequently. If you have a big loop and do a commit within the loop, this may add to log file sync waits as LGWR may not be able to cope up with the speed of posting. You may want to check the alert log and see if you have loads of "checkpoint not complete" messages. In this case, you may look at increasing the redo log size or add more members. But remember, log file sync is a client wait and it doesn't suggest anything with the size of redo logs. You will have to check the application or the process and make sure you don't commit too frequently. That's the only thing you can do on this and in fact, you have to do that.
For ex, if you have a loop like this
Begin
For i in 1..100000000
Loop
   Update tab set col1 = 'blah' where key = i;
   commit;
End Loop;
End;
/You will have to rewrite the above code something like this
Declare
v_count Number := 0;
Begin
For i in 1..100000000
Loop
v_count := v_count +1;
Update tab set col1 = 'blah' where key = i;
If (v_count >= 50000) Then ---some good number.
    commit;
    v_count := 0;
End If;
End Loop;
commit;
End;
/

Waits on log file sync

when i look at oem dbconsole, i see that waits on log file sync has %98 bad impact on my database. dbconsole says that :
finding : Waits on event "log file sync" while performing COMMIT and ROLLBACK operations were consuming significant database time.
Action : Investigate the possibility of improving the performance of I/O to the online redo log files
what can be done for this error?

what can be done for this error? This is not an error,its a wait events.
when user perform commit/rollback then information in logbuffer will be flush to redo logfile by lgwr process.and user session will wait until all this activity process has to complete after commit.
try following actions
log file sync
When a user session commits (or rolls back), the session's redo information must be flushed to the redo logfile by LGWR. The server process performing the COMMIT or ROLLBACK waits under this event for the write to the redo log to complete.
Actions
If this event's waits constitute a significant wait on the system or a significant amount of time waited by a user experiencing response time issues or on a system, then examine the average time waited.
If the average time waited is low, but the number of waits are high, then the application might be committing after every INSERT, rather than batching COMMITs. Applications can reduce the wait by committing after 50 rows, rather than every row.
If the average time waited is high, then examine the session waits for the log writer and see what it is spending most of its time doing and waiting for. If the waits are because of slow I/O, then try the following:
[b] * Reduce other I/O activity on the disks containing the redo logs, or use dedicated disks.
* Alternate redo logs on different disks to minimize the effect of the archiver on the log writer.
* Move the redo logs to faster disks or a faster I/O subsystem (for example, switch from RAID 5 to RAID 1).
* Consider using raw devices (or simulated raw devices provided by disk vendors) to speed up the writes.
* Depending on the type of application, it might be possible to batch COMMITs by committing every N rows, rather than every row, so that fewer log file syncs are needed.
kuljeet

IPhone File Transfer Speeds

I have two MacBooks and two iPhones and I'm seeing very different file transfer speeds between the two. Both have the backup option manually disabled to improve sync times.
Setup 1: iPhone 3GS with MacBook Pro (15-inch, Late 2008) model
Setup 2: iPhone 3G with Black Macbook (13-inch Mid 2007) model
The time it takes to sync video between the two is drastic with the newer model copying files in a few seconds, and the older setup copying files over 5-10 minute periods.
I have yet to swap the two iPhones on the two computers but from a technical perspective, I don't understand why one would transfer files faster than the other. Both are using USB 2.0 and I've already tried using the same cable for both. Anyone see similar behavior? Is this a facet of the older computer or older iPhone?

As an example, a USB host on a PCI bus will send or receive the data via the PCI bus; the stack will prepare the next data in memory and receive interrupt from the host. That's what I mean, how that's implemented.

ATV sync speed super stupid slow.

How quickly does it take you to sync one 45 minute TV show from your ATV to your computer? Mine takes me about 45 minutes. Is this normal? If not, how can i speed this up? I have a wireless Linksys router that hasn't been slow transferring files from my MBP to my G5, or any other capacity. If it is the ATV, why does the sync speed blow?

Well, it's new in that it's always been this way since i bought it new. It's just always seemed slow. It took about 2 hours to sync 8 shows from X-Files Season 2 last night. That works out to being about 2.5 GB, but that STILL seems super slow for this network. I have no issues streaming, so i wonder if this length is supposed to happen.
Now, just to be clear, i have a wireless Linksys router (WRT54G V8). I'm pretty savvy re: computers, but i'm a bit weak on networks, so it might not be optimized. I know sometimes my handheld phone can interfere with me streaming to my airport, but only when it is in use.
Otherwise, the router is hardwired to a Comcast modem. Thoughts?

Block file sync

Hi how can we block users from uploading files to cloud storage ?
Murugan

Hi,
The number of commits can be retrieved from v$sysstat and v$sesstat.
There are no commit statements in any trace file,
you need to look at lines starting with XCTEND in the raw trace data.
Also the size of the log_buffer has 0 to do with the log file sync event, and setting big log_buffer is the typical 'more is better' tuning which doesn't help.
You need to investigate the speed of the devices with holding online redolog, do NOT locate online redologs on RAID-5 devices.
Also posting 'Any one ??' when you are not getting response immediately shows you don't seem to understand this is a volunteer forum.
Sybrand Bakker
Senior Oracle DBA

Performance Issue: Wait event "log file sync" and "Execute to Parse %"

In one of our test environments users are complaining about slow response.
In statspack report folowing are the top-5 wait events
Event Waits Time (cs) Wt Time
log file parallel write 1,046 988 37.71
log file sync 775 774 29.54
db file scattered read 4,946 248 9.47
db file parallel write 66 248 9.47
control file parallel write 188 152 5.80
And after runing the same application 4 times, we are geting Execute to Parse % = 0.10. Cursor sharing is forced and query rewrite is enabled
When I view v$sql, following command is parsed frequently
EXECUTIONS PARSE_CALLS
SQL_TEXT
93380 93380
select SEQ_ORDO_PRC.nextval from DUAL
Please suggest what should be the method to troubleshoot this and if I need to check some more information
Regards,
Sudhanshu Bhandari

Well, of course, you probably can't eliminate this sort of thing entirely: a setup such as yours is inevitably a compromise. What you can do is make sure your log buffer is a good size (say 10MB or so); that your redo logs are large (at least 100MB each, and preferably large enough to hold one hour or so of redo produced at the busiest time for your database without filling up); and finally set ARCHIVE_LAG_TARGET to something like 1800 seconds or more to ensure a regular, routine, predictable log switch.
It won't cure every ill, but that sort of setup often means the redo subsystem ceases to be a regular driver of foreground waits.

I think my sync speed is stuck or been capped

Hi everyone, last week i had a full line reset because i started dropping in speed, from 16meg al the way down to 9meg, at the time time of the reset my sync speed went to 12.5meg, 24 hours later i was down to 9.494meg down and 1.12 up, im supposed to be on another 10day training but nothing has happened, meaning the hhb3 hasnt switched off or resynced since i dropped to 9.4meg, now after 5 days of constant connection there was still no change so i did a something to try and make my speed drop but nothing happened, it still synced at the exact same speed 9.4meg, im certainly not rate adaptive and i cant have any line issues or my speed would of dropped after constantly plugging in and out the socket and making it resync, so the only things i can come up with is that ive either been capped or the exchange has got stuck for some reason, ive even gone through my entire extension wiring and changed it to cat6, it made my line attenuation lower but no change in sync rate heres my speed test and hub stats.
ADSL Line Status
Connection Information
Line state:
Connected
Connection time:
0 days,
04:02:35
Downstream:
9.494 Mbps
Upstream:
1.129
Mbps
ADSL Settings
VPI/VCI:
0/38
Type:
PPPoA
Modulation:
G.992.5 Annex
A
Latency type:
Fast
Noise margin
(Down/Up):
10.4 dB / 5.9
dB
Line attenuation
(Down/Up):
29.3 dB / 13.3
dB
Output power
(Down/Up):
18.1 dBm / 12.0
dBm
FEC Events
(Down/Up):
0 / 0
CRC Events
(Down/Up):
207 / 76
Loss of Framing
(Local/Remote):
0 / 0
Loss of Signal
(Local/Remote):
0 / 0
Loss of Power
(Local/Remote):
0 / 0
HEC Events
(Down/Up):
727 / 45
Error Seconds
(Local/Remote):
233 / 89
FAQ
<script type="text/javascript">// paintProgressAndMessageOnBar(100,"The test has successfully completed" ); // </script>
Test1 comprises of two tests
1. Best Effort Test: -provides background information.
Download Speed
8135 Kbps
0 Kbps
21000 Kbps
Max Achievable Speed
Download speedachieved
during the test was - 8135 Kbps
For your connection, the acceptable
range of speeds is 4000-21000
Kbps.
Additional Information:
Your DSL Connection Rate
:9721 Kbps(DOWN-STREAM), 1155 Kbps(UP-STREAM)
IP Profile for
your line is - 8576 Kbps
2. Upstream
Test: -provides background information.
Upload Speed
897 Kbps
0 Kbps
1155 Kbps
Max Achievable Speed
>Upload speed
achieved during the test was - 897 Kbps
Additional
Information:
Upstream Rate IP profile on your line is - 1155
Kbps
We were unable to identify any
performance problem with your service at this time.
It is possible that any
problem you are currently, or had previously experienced may have been caused by
traffic congestion on the Internet or by the server you were accessing
responding slowly.
If you continue to encounter a problem with a specific
server, please contact the administrator of that server in the first
instance.
Please visit FAQ
section if you are unable To understand the test results.
Solved!
Go to Solution.

Thanks for your replys, believe it or not my line as been more stable, meaning alot less disconnects,infact very rare since i last had the snr reset, it auto changed to fast when mods manually reset the snr a month ago, i think it sounds like a joint or something, def not my internal wiring, its all brand new as of today and theres no change in sync so, the prob lies else where, i tried to tell bt before that theres some kind of fault between the pole and the exchange last time my speed dropped when i was on adsl max, it dropped to 300k i think, i rang up for a mac code because they wouldnt acknoweldge the fact and gottalked into adsl2+, everything went well untill 3 weeksago(around that time) i was up to 16meg sync, i posted it on here, after opening my big mouth my speed started to drop so i had a manuall snr reset, that solved it for a while, then i had that bad weather and it all screwed up, like i said previous, about 10-20mins before the reset my sync dropped to 1meg and line attenuation shot up to 65db, after the reset i had 12.5meg, 24 hours later i was down to 9meg, person on the other end of the phone at bt said my minimum sync should be around 12meg

Questions and answers on DLM, sync speed and real ...

I was confused about some DML details and posted on a BE forum (https://avatar.bethere.co.uk/forum/viewtopic.php?t=43542) and got what was to me an incredibly helpful response from Tom (drsox). I thought it would be of interest to some readers here so copy it below. Once again, many thanks Tom.
1) FTTC DLM applies only between the cabinet and the modem?
>> Yes, as there isn't any broadband / data signal going anywhere further down the line to the exchange if you are on FTTC!
2) What are the different parameters that apply on this hop? I know there is a current sync speed, a current snr, a target snr and an ip profile. Anything else?
>> The IP profile isn't really related to DLM, it just "follows" your sync rate. In the past the IP profile would take up to 3 days to "follow upwards", leaving you with a high sync and awful speeds! This has been changed now on 21cn and "RE-ppp"ing (rebooting the router) would force the IP Profile to update instantly.
DLM changes the SNR target. So where BE have hard coded / set SNR targets such as 3db, 6db, 9db, 12db etc.. They only change upon user request. BT use their DLM system where line instability or line error counts are collected and analysed, the SNR target and interleaving settings are then modified in increments to try and stabilise the line.
This image shows quite well how, over a 6 day period, BTs DLM noticed that my line fault was fixed. I didn't get the full speed back for a week.
3) Is the ip profile the same as the BRAS profile?
>>Yes
4) The DLM keeps statistics of errors etc to dynamically change the ip profile?
>> Changes the SNR target and interleaving for the line which will reduce the speed, and therefor the IP profile.
5) There is a general theory that the DLM is incapable of telling the difference between an error and a modem power cycle, so that power cycling can cause your profile to lower. Is that correct?
>> Yes, if you resync / power cycle your router multiple times in a day it is likely to try and "combat the line errors" and reduce your sync rate by increasing the SNR and / or interleaving on the line.
6) Can other connections and disconnections have the same effect? For example, if I reboot the router (where this is separate from the modem)? Or use the router interface to disconnect/reconnect the broadband?
>> PPP drops (router reboots while leaving the BT Openreach VDSL modem on and connected) won't affect DLM. The IP profile will match your sync rate upon reconnection of the PPP session.
7) If you have a low ip profile, does this mean that the sync is limited to the ip profile?
>> Other way around, if you have a low sync rate then the IP profile will match the sync rate. If you get an awful sync rate and the IP profile follows downwards, then you resync higher but the router "keeps the PPP session open" (which is possible if you resync quick enough) then your IP profile will stay low, even though the sync is high. Until you reboot your router or disconnect and reconnect the PPP session.
8) Can the sync rate change dynamically without a reconnection? If the ip profile gradually rises, will the cabinet force a resync to make sure the customer is actually getting the benefit of the higher ip profile, or must the user intervene with a modem resync?
>> See above - Sync can rise without affecting the IP Profile and the cabinet does not force a RE-PPP.
8) As I understand it, if the ip profile gets stupidly low for some reason, it can only be reset by BT wholesale? This will only be done after a visit to your home and a telephone call from the engineer to the BT wholesale central admin?
>> Mixed reports plus I don't think people understand the difference between sync speeds, line faults, the delay in DLM increasing sync after a fault.. I expect half the reports on the BT forum are not related to a stuck BRAS / IP profile. It is possible for the ISP or a BT engineer to reset the IP profile and possibly DLM training.
9) (8) This applies to all ISPs using BT Wholesale: some may be more willing to force this process to happen on behalf of their customers, but none can cirumvent it?
>> GEA providers (I believe) still have DLM but don't have BRAS / IP profiles unless they implement their own.
10) Who sets the snr? As I understand it, the customer has no direct control. Is this different for different ISPs?
>> Mixed information again, I believe that BT Wholesale give providers DLM override controls and SNR settings but none? (or few) ISPs use this system.
11) Real download/upload speeds are physically limited by the sync rate. They are also naturally limited by local limitations (such as wireless connections), server limitations, and congestion at various points along the route? Any more? The congestion along the route will vary bewteen ISPs as they use different routes with different capabilitues.
>> It is possible for BTs regional or local cabinet network to become congested. Supposedly the minimum speed you should achieve over the BT part of the network is 15mbps. ISPs such as Plusnet, BT etc.. then layer their own "discriminatory" traffic management on top of that (ie, slow down torrents etc.).
12) Real speeds are 'unnaturally' limited by throttling. This will also vary from ISP to ISP. Sky claims to have none, and BT none except for p2p. PlusNet and John Lewis have significant (but well explained)throttling. All the more expensive operators have none.
>> What you said
13) The ip profile affects the sync rate, and therefore actual speeds. Does the ip profile effect actual speeds in any other way?
>> Not quite right. The IP profile directly affects the speeds you can achieve but the sync rate affects the IP profile. The sync rate is determined by the stability and quality of your line and what DLM thinks it can cope with.
14) Many people (including AndrueC above) report real speeds from speedtests that are consistent and not close to the ip profile. These can't be explained by congestion (that would make them inconsistent). They can't be explained by server limitations, as they are consistent accross servers and the same servers give better speeds to other people. They can't be explained by local limitations, too many people claim sudden drops where the local conditions have not changed. They should not be able to be explained by throttling, as they as seen for many ISPs who do not throttle (I don't hold with the ISP lying theory here). What other factors are there that can explain these cases?
>> AndrueC and some other Sky customers have strange symptoms where speeds are around 20mbps rather than the full sync speed. The only logical explanation is either local cabinet congestion, contention between BT and the provider's network (not enough investment by the provider) or artificial traffic management on the providers side. It is also possible that the router that the customer has attached to their line is unsuitable for the higher speeds. For example an old ethernet router may only be able to cope with 20 or 30mbps! A friend of mine has a TP-Link ethernet router running Tomato on a BT 80mbps service but the TP-Link's CPU limitation causes his service to only perform at around 68mbps; he has a replacement router on order. (Obviously wifi will significantly reduce performance).
15) If you get a stupidly low ip profile, how long can you except it to take before it climbs to something more reasonable? (eg in my particular case, my profile is currently around 15Mb, and from BT service line tests should be around 58Mb). And the classic question, is it best to power cycle the modem (1) never, (2) occasionally (how often) or (3) never if at all possible? Mine did jump from 3.5Mb to 15Mb on one power cycle. Was that just coincidence?
>> My FTTC line took about 6 to 7 days to go from 40mbps to 80mbps after a line fault. It is possible that your 3.5mbps to 15mbps increase was the "re-ppp" affecting the BRAS profile and that your sync had slowly been increasing over time.

what a waste of money sending an engineer to "fix a fault" which does not exist. Precisely.
In my original BE post to which Tom so helpfully responded, I began: It seems to me that DLM is an excellent concept with a highly flawed implementation, both technically and administratively. I think that sending out an engineer to fix an obviously flawed profile is the main example of an adminastrative flaw. I understand (I can't remember source, maybe Tom again) that they are sometimes relaxing the requirement for a visit before reset.
Maybe the DLM system is too keen on stability vs speed. This will keep complaints down from many people: most users won't notice speed too much as long as it is reasonable, but will be upset if their Skype calls and browsing are being interrupted too often.
However, it does lead to complaints from people who notice the drops after an incidence (as in your thread that has drawn lots of interest), or who only get 50 instead of 60. The main technical flaw is that DLM can so easily be confused by drops from loss of power, too much modem recycling, etc, and then takes so long to recover.

File sync speed, reliability

Similar Messages

Maybe you are looking for