OneDrive for Business large file upload

Hi Tony,
Just thought I’d share my experience for the last 24 hour or so.
I left my laptop syncing overnight. Based on the upload speed of my broadband connection I would have hoped for 4 to 5 of my large files to upload.
I the morning , only 1 of those files had uploaded successfully. There were some more in the "waiting queue " but there were also 5 files in the “not allowed” queue with the error “You are no longer logged into Microsoft”. A little more worryingly was that there was a popup on my screen with a system error saying that “F:\odrive” is unavailable. “F:” is a physical external USB self-powered disk and is where my odrive folder is located. I’ve never seen an error like that under normal operation. My onedrive client folder used to the on that disk too but I never had an error like that. Anyway, the error popup was also accompanied 3 new open explorer windows which was very strange and I had left nothing open on the laptop before leaving it for the night. Stranger still was that the odrive sync client was still running and in the middle of trying to upload a file which I could see was actively transferring from the storage management console in my 365 tenancy. There was definitely no power cut as I would have seen various appliances in my home with reset clocks.

Anyway, something had obviously gone seriously wrong overnight so I stopped the odrive client and rebooted. I also set the “split-file” option to see if I could get any better success in file uploads. I set the split file to 2GB and kicked off the sync client again.
So far during the day I have noticed that

  1. I have had very many 2GB file “chunks” upload successfully.
  2. I have also seen quite a few file chunks get to the end of of the upload only for the file to disappear again so presumably had gotten corrupted on the way?
  3. I have seen many files go into the “not allowed” queue for the reason of “You are no longer logged into Microsoft”. Later on they move back to the “waiting” queue with no intervention from me.

All of this leads me to believe there is something fundamentally wrong with the stability of onedrive or my ISP connection.

Anyway, I’ll keep any eye on the uploads for another couple of days and report any more anomalies.

Meanwhile, is there anything I can be doing or error logs I can look at to see if there is any indication of the cause of issues?

Thanks,
Sean

Hi @sean,
Can you send a diagnostic from the odrive tray menu and then switch back to not using the split-file option and try the upload again. If/when an error occurs, please send another diagnostic so I can take a closer look at the behavior. It looks like Microsoft is throwing some errors during upload, so we’ll need to see what those are.

Can you tell me what your upload speed is?

For the F:\ drive error, it sounds like the external drive disconnected and then reconnected a few times. odrive doesn’t have any ability to affect physical disk mounting, so it must be some other cause. I have seen this happen during periods of high activity, especially for drives that are powered by the USB ports. These large file uploads coupled with potential background activity that odrive is doing to keep everything in sync could spike the load on the drive enough to cause some power instability. This is one of the reasons why we don’t officially support having the root odrive folder on an external drive.

These disconnects likely happened in the middle of upload, as well, which would disrupt the upload and require a restart (which odrive will do automatically).

Hi Tony,
Thanks for the quick reply.
First things first, I have an upload speed of 25Mbps which can burst up to around 30 at times. Generally when syncing the odrive client is using the full 25Mbps which I can see in task manager.

I think I can discount the USB drive as being the source of any issues (at least since I turned on file splitting) because of my observations since then.
I have been watching odriveapp.exe in task manager and also been keeping an eye on disk activity for the USB drive via task manager and looking at the access LED on the drive.
With file splitting turned on I see that most of the time the disk is idle. The process appears to go like this:
While the client is syncing a 2GB chunk there is no activity on the disk at all and all of the activity of the client is uploading at around the 25Mbps for 10 to 12 minutes . When the chunk is uploaded there is a pause for about 15 to 20 seconds or so of no disk activity and no network activity. I’m guessing this is probably while the integrity of the uploaded file is checked. There then follows around an 8 to 10 second burst of disk activity and then the upload can be seen to start again with the next 2GB chunk. So, I’m guessing that the client reads a 2GB chunk of a file, it gets cached somewhere and is then uploaded.
If I am correct in all of my assumptions and observations then disk access is only 8 to 10 seconds every 10 or 12 minutes. I can’t see how this puts any strain on the disk. Because the disk is dedicated purely for backups there is no other system process that needs to be accessing that disk at any time anyway.

It is the case, though, that some of these 2GB chunks are failing as I have been able to see on the 365 storage management console that a “~tmp” file gets created, gradually grows to 2GB over the next 10 to 12 minutes and then sometimes instead of being renamed without the “~tmp” it simply disappears (presumably having failed the validation and been deleted). That being the case then I would assume that some of the diagnostics you are looking for (onedrive errors) should already be there for some of these failures.
Would it make sense to send these diagnostics?
I don’t really want to lose the files that have “partially” transferred today in 2GB pieces by switching off the splitting feature while they are not complete.
Before I do send any diagnostics, however , can I see the the diagnostics information that is going to be uploaded? I would want to see what is in there for security and privacy reasons.
Thanks and Regards,
Sean

Hi @sean,
Thanks for the additional details!

The file should actually streamed from the disk as it uploads, otherwise it would have to read in the whole thing and then cache it in memory, which would end up consuming 2GB of memory. Do you notice a very large spike in memory when this happens?

odrive will still need to access it to perform background scanning and updates that are unrelated to the current upload. Do you know if you have indexing enabled for that drive?

Yes. Please send them if you are able to.

For the file splitting, keep in mind that the file will end up on the storage in these chunks, so it can only be accessed in this state via odrive clients. For backups this is fine, but not so good if you need to share it or access it from other interfaces.

The diagnostic contains:

  • Your odrive account information: (What service you use to login to odrive and the e-mail associated with it).
  • Version information for the desktop client.
  • Recent sync activity, along with details on the decisions and actions that the sync engine has made and errors that have been encountered.
  • A list of what is currently in the not allowed, waiting, and trash queues.
  • What storage services are linked.

Other notes:

  • It contains metadata information (names, dates, and size) for the files that have been recently synced.
  • It does not contain any data from any of your files
  • It does not contain anything about items that are outside of odrive’s view.
  • The diagnostic data is automatically deleted after 72 hours.

There is also a “current_odrive_status.txt” file that is created when you send diagnostics to can be looked at locally. It is not as detailed as the diagnostics, but will show recent errors, among other things.

Hi Tony,
I’ve sent the diagnostics and I’ll take a more detailed look at the txt file it generated shortly. First thing i noticed was that access tokens expire regularly.

What can I tell you about disk access: I’m seeing what I’m seeing! :slight_smile: I’d be more than happy to set up a Microsoft Teams call with you and show you what I see in real time. It would only take 15 minutes to see at least 1 full cycle of a 2GB transfer. Screen sharing might affect upload rate a little but probably not by much.
There is zero disk access on F: while a file is uploading. The most memory I am seeing being consumed by odriveapp.exe is 150-160 MB but often less. The biggest use of memory by any other process is 390MB and that is my anti-virus. There must be some caching going on somewhere because there is nothing streaming from disk! :slight_smile:
Also, yes, the disk is indexed for both file content and properties.
Let me know if you want to to a Teams screen share.
Regards,
Sean

Hi @sean,
I have been testing against OD4B today, trying to identify any gaps to large file uploads. I’m still going through it, but I may have a version to test non-split uploads (if you are willing to try it), to see if you still encounter the same errors you did before.

Hi Tony,
Yes I’d be willing to try it. I’m impressed by you product so far so if I can help improve it I will. My current uploads will be finished in the next couple of hours (I hope!) and then I could install a beta client and generate some new large backup files and turn file splitting off.

Fyi… On the subject of caching, I took a look with sysinternals RAMMap using the file summary tab and it looks like Windows itself is caching the files in RAM . I have 16 GB of RAM on the laptop and when there is not much else going on except the uploads it looks like Windows cache manager is taking advantage of that and doing the caching itself. Will look at it some more when I get a chance but pretty sure that is what is going on with the small busts of disk access between uploads of the 2GB chunks.
To be honest , in the long term, I’m probably going to leave the file splitting on to take advantage of this and to minimise the size of re-tries in the event I do have network or onedrive issues. Still happy to work with you, though, on improving the large file uploads without splitting of course.
Regards,
Sean

Just fyi …
I’m down to my last file for upload and it is a 30GB file. File splitting is still turned on and set at 2GB.
Seven 2GB file pieces have uploaded so far but the 8th piece has failed twice now.
What I am seeing is that the “~tmp” file uploads and reaches 2GB in size then disappears.
I generated diagnostics and the timing of these failures coincides with the following error each time :

SystemException(code ODB_RATE_LIMITED caused by OneDriveForBusinessRateLimitingException(code ODB_RATE_LIMITED - {“error”:{“code”:“serviceNotAvailable”,“message”:“Service unavailable”,“retryAfterSeconds”:120}}))

I found this:
https://docs.microsoft.com/en-us/sharepoint/dev/general-development/how-to-avoid-getting-throttled-or-blocked-in-sharepoint-online
Don’t know if it is relevant?

Hi @sean,
Thanks for this information. I’ve noticed Microsoft throwing these “Service unavailable” errors more often, recently. It is actually different than their typical rate limiting exceptions (Too many requests), but is treated the same.

I am looking at how we can better account for this during the file splitting flow since it goes through a few translation layers and isn’t as smooth as a “direct” upload.

I would expect that the chunk has probably gone up now, but if not, you can try pausing sync for a little bit (Stop automatic sync in the odrive tray menu) and then enabling it again.

Since you are using file splitting, I also wanted to point out that the format, among other things, is documented in this blog post here: https://medium.odrive.com/cloud-upload-was-a-struggle-until-today-bb267cb5566e

I also have a small utility that can automatically assemble split files here: https://github.com/amagliul/odrive-utilities

This shouldn’t ever be needed, but it nice for folks to know.

Thanks Tony,
That blog you referenced is what actually prompted me to try file splitting yesterday!

I did try pausing the upload a couple of hours ago and left it for a half hour or so before turning it on again. A couple more chunks uploaded after that but then started failing again.
I’m just going to leave sync switched off for now and switch it on again tonight well after business hours.
The storage for my tenancy is in Europe so hopefully there won’t be as much throttling tonight.

Regards,
Sean

1 Like

Hi Tony,
I ran a quick test of Google Cloud Storage (not Google drive) last night and uploaded a 22.5Gb file in just a little over 2.25 hours (without file splitting) and without a single error and essentially using the full capacity of my upload speed. That’s Impressive. It’s just a pity that Google pricing makes it almost twice as expensive for just 1TB of Nearline storage (best for backups it seems) as my entire MS-365 subscription which gives me all the MS Apps,Teams etc PLUS the 1TB of OD4B storage. Considering I would have to pay again to download the data from Google Nearline if I ever needed it and would not have to pay for download from OD4B it makes Google cost prohibitive for my needs which is a pity. I guess you get what you pay for though in terms of cloud storage performance!! . Based on that simple test , though, I’m going to have to fully agree with your blog that deemed it (Google Storage) the best Cloud Storage option!
Anyway, for now I’m stuck with what I’ve got which is OD4B and I generated a diagnostic after the Google test which confirmed that there were no Google errors but did show a LOT of OD4B errors from earlier in the day which led me to some musings about OD4B errors and handling by the odrive client. I’ll put those into a separate post following this one.
Regards,
Sean

Hi Tony,

Putting this in a separate reply as it purely deals with OD4B errors and not my observations of Google Cloud Storage.
So, as I mentioned above, you can hopefully see the diagnostics I generated at 22.09 Irish time last night (14th). Between that diagnostic and a couple of previous ones , the types of errors I have seen fall into these categories and I’ve included my “semi-educated” musings. These musings are based on the assumptions that (a) odrive client is trying to use the OD4B resume capabilities of the upload API (b) that the client will give up trying to upload a file after a number (maybe 2 or 3?) of attempts to upload a particular file and move on to the next file in the “waiting queue” © that maybe the odrive client is not handling or honoring OD4B errors in the best way

The errors and my thoughts:
(Note: Some file names redacted for privacy)

  1. “Rate Limited until …”

01:36:43PM 2244 14256 RAISED remote_list_folder([u’uri=/34bcfe7a-e0db-4aff-a56f-cb52a75a514f-5f0ad7e0’, u’pageToken=None’]) --> SystemException(code ODB_RATE_LIMITED - OneDrive for Business is currently Rate Limited until 1594730321.91)

01:36:57PM 2244 14256 RAISED remote_list_folder([u’uri=/34bcfe7a-e0db-4aff-a56f-cb52a75a514f-5f0ad7e0’, u’pageToken=None’]) --> SystemException(code ODB_RATE_LIMITED - OneDrive for Business is currently Rate Limited until 1594730321.91)

01:36:57PM 2244 10800 RAISED remote_list_folder([u’uri=/34bcfe7a-e0db-4aff-a56f-cb52a75a514f-5f0ad7e0/01L3O3EULNNGBYXU4ZXZGLIA54HG53Z6B5’, u’pageToken=None’]) --> SystemException(code ODB_RATE_LIMITED - OneDrive for Business is currently Rate Limited until 1594730321.91)

01:37:45PM 2244 12980 RAISED remote_list_folder([u’uri=/34bcfe7a-e0db-4aff-a56f-cb52a75a514f-5f0ad7e0/01L3O3EULNNGBYXU4ZXZGLIA54HG53Z6B5’, u’pageToken=None’]) --> SystemException(code ODB_RATE_LIMITED - OneDrive for Business is currently Rate Limited until 1594730321.91)

01:37:59PM 5912 13236 RAISED apply_local_expand_file([u’cloudO2Path=F:/odrive/OneDrive For Business/****************************.pdf.cloud’, u’remoteAttr=FileAttributes(id=u\’/34bcfe7a-e0db-4aff-a56f-cb52a75a514f-5f0ad7e0/01L3O3EUMMDC6ZTA3X2JFKUZTSMCJU7TUS\’, name=u\’****************************.pdf\’, isFolder=False, size=284934, modTime=1582207334, uri=u\’/34bcfe7a-e0db-4aff-a56f-cb52a75a514f-5f0ad7e0/01L3O3EUMMDC6ZTA3X2JFKUZTSMCJU7TUS\’, contentTag=u\’“c:{99BD188C-7783-4AD2-AA66-7260934FCE92},2”\’)’]) --> SystemException(code ODB_RATE_LIMITED - OneDrive for Business is currently Rate Limited until 1594730321.91)

01:38:11PM 5912 14952 RAISED apply_local_expand_file([u’cloudO2Path=F:/odrive/OneDrive For Business/****************************.pdf.cloud’, u’remoteAttr=FileAttributes(id=u\’/34bcfe7a-e0db-4aff-a56f-cb52a75a514f-5f0ad7e0/01L3O3EUMMDC6ZTA3X2JFKUZTSMCJU7TUS\’, name=u\’****************************.pdf\’, isFolder=False, size=284934, modTime=1582207334, uri=u\’/34bcfe7a-e0db-4aff-a56f-cb52a75a514f-5f0ad7e0/01L3O3EUMMDC6ZTA3X2JFKUZTSMCJU7TUS\’, contentTag=u\’“c:{99BD188C-7783-4AD2-AA66-7260934FCE92},2”\’)’]) --> SystemException(code ODB_RATE_LIMITED - OneDrive for Business is currently Rate Limited until 1594730321.91)

01:38:22PM 5912 8996 RAISED apply_local_expand_file([u’cloudO2Path=F:/odrive/OneDrive For Business/****************************.pdf.cloud’, u’remoteAttr=FileAttributes(id=u\’/34bcfe7a-e0db-4aff-a56f-cb52a75a514f-5f0ad7e0/01L3O3EUMMDC6ZTA3X2JFKUZTSMCJU7TUS\’, name=u\’****************************.pdf\’, isFolder=False, size=284934, modTime=1582207334, uri=u\’/34bcfe7a-e0db-4aff-a56f-cb52a75a514f-5f0ad7e0/01L3O3EUMMDC6ZTA3X2JFKUZTSMCJU7TUS\’, contentTag=u\’“c:{99BD188C-7783-4AD2-AA66-7260934FCE92},2”\’)’]) --> SystemException(code ODB_RATE_LIMITED - OneDrive for Business is currently Rate Limited until 1594730321.91)

01:38:33PM 5912 14352 RAISED apply_local_expand_file([u’cloudO2Path=F:/odrive/OneDrive For Business/****************************.pdf.cloud’, u’remoteAttr=FileAttributes(id=u\’/34bcfe7a-e0db-4aff-a56f-cb52a75a514f-5f0ad7e0/01L3O3EUMMDC6ZTA3X2JFKUZTSMCJU7TUS\’, name=u\’****************************.pdf\’, isFolder=False, size=284934, modTime=1582207334, uri=u\’/34bcfe7a-e0db-4aff-a56f-cb52a75a514f-5f0ad7e0/01L3O3EUMMDC6ZTA3X2JFKUZTSMCJU7TUS\’, contentTag=u\’“c:{99BD188C-7783-4AD2-AA66-7260934FCE92},2”\’)’]) --> SystemException(code ODB_RATE_LIMITED - OneDrive for Business is currently Rate Limited until 1594730321.91)

My thoughts: It seems to me that at 01:36:43PM the odrive client should have honored the OD4B response and backed off until 01:38:42PM (assuming the OD4B response is in UTC unix time and my Log times are Local to my laptop i.e. Irish). Instead it made multiple attempts at list and delete operations. The result seems to have been in the case of the uploads that 2 successive errors forced then client to move on to the next file whereas I think it should have waited (as this then probably compounds another “resume transfer” operation failure later on in my list where the client eventually loops back around to retrying one of the failed files but the upload token for resuming has expired.

  1. “retryAfterSeconds …”
    08:59:45AM 2064 1160 RAISED apply_remote_add_xl_file([u’parentUri=/34bcfe7a-e0db-4aff-a56f-cb52a75a514f-5f0ad7e0/01L3O3EUJNNN27LZMFDVA25JF4ML5ZPM7U’, u"localAttr=FileAttributes(id=u’3767504667:983040:146’, name=u’978F8484A4AF0952-00-03.mrimg’, isFolder=False, size=31138347115L, modTime=1594476211, uri=u’F:/odrive/OneDrive For Business/MacriumBackups/Erazer/978F8484A4AF0952-00-03.mrimg’, contentTag=None)", u’name=978F8484A4AF0952-00-03.mrimg.6d2e045338268bf511f2242cda0e4bcc’]) --> SystemException(code ODB_RATE_LIMITED caused by OneDriveForBusinessRateLimitingException(code ODB_RATE_LIMITED - {“error”:{“code”:“serviceNotAvailable”,“message”:“Service unavailable”,“retryAfterSeconds”:120}}))

08:59:45AM 2064 8296 RAISED remote_list_folder([u’uri=/34bcfe7a-e0db-4aff-a56f-cb52a75a514f-5f0ad7e0/01L3O3EUJNNN27LZMFDVA25JF4ML5ZPM7U’, u’pageToken=None’]) --> SystemException(code ODB_RATE_LIMITED caused by OneDriveForBusinessRateLimitingException(code ODB_RATE_LIMITED - {“error”:{“code”:“serviceNotAvailable”,“message”:“Service unavailable”,“retryAfterSeconds”:120}}))

08:59:45AM 2064 8296 RAISED apply_remote_add_xl_file([u’parentUri=/34bcfe7a-e0db-4aff-a56f-cb52a75a514f-5f0ad7e0/01L3O3EUJNNN27LZMFDVA25JF4ML5ZPM7U’, u"localAttr=FileAttributes(id=u’3767504667:786432:483’, name=u’978F8484A4AF0952-00-04.mrimg’, isFolder=False, size=31138367371L, modTime=1594477470, uri=u’F:/odrive/OneDrive For Business/MacriumBackups/Erazer/978F8484A4AF0952-00-04.mrimg’, contentTag=None)", u’name=978F8484A4AF0952-00-04.mrimg.72c35a5558396cc5992ccdc36f913143’]) --> SystemException(code ODB_RATE_LIMITED caused by OneDriveForBusinessRateLimitingException(code ODB_RATE_LIMITED - {“error”:{“code”:“serviceNotAvailable”,“message”:“Service unavailable”,“retryAfterSeconds”:120}}))

My thoughs: Again, it seems the odrive client should honor the retry period and back off for the 120 seconds requested. Instead it seems that the client gave up on this attempt after the three errors?

  1. “The access token has expired”
    03:36:22PM 7816 2004 RAISED apply_remote_add_xl_file([u’parentUri=/34bcfe7a-e0db-4aff-a56f-cb52a75a514f-5f0ad7e0/01L3O3EUJNNN27LZMFDVA25JF4ML5ZPM7U’, u"localAttr=FileAttributes(id=u’3767504667:327680:488’, name=u’978F8484A4AF0952-00-09.mrimg’, isFolder=False, size=31138486153L, modTime=1594481976, uri=u’F:/odrive/OneDrive For Business/MacriumBackups/Erazer/978F8484A4AF0952-00-09.mrimg’, contentTag=None)", u’name=978F8484A4AF0952-00-09.mrimg.705649f54f3069506e97bde0b2520745’]) --> RefreshTokenRequestException(code ODB_SESSION_EXPIRED caused by OneDriveForBusinessLoginRequestException(code ODB_SESSION_EXPIRED - {“error”:{“innerError”:{“code”:“expiredToken”},“code”:“unauthenticated”,“message”:“The access token has expired. It’s valid from ‘7/13/2020 1:20:45 PM’ and to ‘7/13/2020 2:25:45 PM’.”}}))

My thoughts: Maybe this is compounded by the fact that the odrive client seems to give up on the transfer of some files as a result of errors in 1. and 2. above and because I could have multiple large files in the waiting queue it could be a long time before the client gets around to trying to resume a previously failed (interrupted) upload. By the time it loops back around the token has expired and the file has to start transmitting again. I think this would be detrimental to large file uploads particularly if file splitting is turned off.

Granted, my testing and review of diagnostics has been somewaht limited and I am maked some semi-educated guesses and assumptions but I havent seen so far that a “retryafter” or “ratelimited until” requests the client to back off for any longer than 2 minutes so I wouldn’t imagine that honoring these and pausing the client for the requested time would be too detrimental??

Anyway, hope my thougts are helpful and would appreciate it to know if I am anywhere close to the mark :slight_smile:

Regards,
Sean

Hey @sean!

Thanks for the information and your thoughts. In my own testing, as with yours, Google certainly seems to have a much more “stable” and performant service.

I think OD4B has developed into a a bit of a Frankenstein’s monster over the years, since it incorporates several different types of sub-services and back-ends. The challenge is trying to account for the exceptions to keep things flowing. OD4B requires a lot of “special handling”…

We’re currently looking at the best way to handle some of these OD4B errors, especially on longer-running actions, like large file upload. There are a couple of gaps still.

Your thoughts on the rate limiting are definitely in the right direction. The “Rate limited until” message is actually an internal exception that we are throwing. In those cases we aren’t actually making any external calls because we are blocking locally until the wait time expires. For requests that are attempted during this time, they should wait and then retry, but your logs are showing that we are not waiting long enough to really matter. I’m going to dig into this more to see where the disconnect is.

There is also a gap in the split file logic. It goes through a few abstracted layers and is not handling longer rate limits and access token expiration properly, at least for OD4B. Something that seems to be new that I’ve noticed in my testing (and your logs) is that OD4B is allowing the token to expire in the middle of a chunked upload, which is… inconvenient. Generally there is more flexibility given on these types of successive operations.

In any case, we’re going to keep banging away on these annoying issues to close the gaps where we can. I really appreciate your help in nailing some of these things down. In my testing yesterday I wasn’t able to trigger a “natural” rate limit exception on OD4B, and had to simulate it, so your logs definitely help to show the real errors you are encountering.

Thanks Tony.
If you want me to run any more tests or try any beta versions of the client, just let me know.
I’m pretty sure I can trigger some “natural” rate limits just by trying to upload one of my larger backups during the working day.
My backups are set to run in the middle of the night so might not generate the rate limits under a normal schedule but I can always trigger one to run at any time of the day.

As it happens , there is an incremental backup scheduled for just after 1AM tomorrow morning and the disk being backed up has had several GB added to it since the last incremental so I might have some more useful diagnostics to share tomorrow. I’m going to leave file splitting on for now anyway to avoid a lot of lost time if a bigger upload fails and has to retry.

Otherwise, you might let me know when there is any new version of the client that I can download that addresses the OD4B difficulties.

Regards,
Sean

1 Like

Hi @sean,
Here is a new version that tweaks a few things. I would be curious to know how it handles uploads direct to OD4B and split-file uploads.

Only if you have the time, of course: https://www.odrive.com/s/10c95edd-3979-45ae-84ae-09e4c1fedabf-5f101587

1 Like

Yep. I’ll try it. Probably around lunchtime today.
Can I install that version straight over the top of the existing (assuming I quit the client first) ?
Would prefer not to mess around with uninstalling the old with the potential of losing the content in the odrive root folder that is there at the moment.
(Installing over the top worked for the last beta I installed and I rebooted afterwards to be on the safe side)

Hi @sean,
Yes, you can just upgrade with this version, no uninstall needed.

Hi Tony,
I only got around to kicking off this test at around 3.50PM Irish.
I turned off file splitting and dropped two 30GB files into a folder for upload to OD4B.
I’m 16GB into the upload of the first file and no issues so far to report.
During the first half hour or so I saw what I am interpreting as occurrences of “backing off” by the client due to OD4B throttling. What I was seeing was that in Task Manager the client would stop any network upload. CPU and disk usage would drop to zero also. It would stay this way for a couple of minutes (probably around 2 minutes) and then try to start uploading again. Sometimes it would “back off” again very quickly. Sometimes it would run for quite a while before “backing off”. Now that we have come to the end of the working day across Europe I’m not seeing any of this “backing off” any more.
If it gets both files uploaded successfully I’ll generate some diagnostics for you to look at. If I see any issues I’ll also generate diagnostics and let you know.
Regards,
Sean

1 Like

Thanks @sean! I am definitely curious to know how it goes.

First file went up fine. Second has about 10GB to go. No issues to report so far :slight_smile: Fingers crossed.

1 Like