Sooo... there's a good reason there's a lot of different information on this... mostly related to the fact that there's some misunderstanding and due to a defect that's never been addressed.
Out of the gates, I should recommend not using the Schedule Updates and Distribute Updates features at the same time... they simply don't play well together. I'm fully aware of the obsurdity of that, but it's just the way it is right now... and probbaly the way it always will be.
Can someone please explain how this formula is used by Symantec (or if)? Sure, this tells us the total time it should take to distribute the clients. But is Symantec using this equation somehow to determine how it schedules the updates? Where are the number of days I specified taken into consideration? If I put in a 5 hour block over 2 days and the server thinks it will take 15 hours, does it ignore what I put in? How does it calculate "Server Transfer Rate", etc.?
We do use a formula (I think it's listed if you click the Help button) to calculate a schedule for all the clients, but I don't know if it's the one that's listed. As far as I'm aware, the formula you've given is not used by the SEPM... it's supposed to help you figure out how long to set the "Distribute Updates over X" setting. We take whatever time you put there and divide the clients evenly along that time line. Example: If you have 2 clients and set it to distribute over 30 days, the first one will go immediately and the second will go after 15 days.
Using Distribute Clients over X days will assign a time to each client and only allows the client to get the update at that time. If the client misses it, it doesn't get the update until the cycle starts over. Example: That client that had to wait 15 days is offline on Day 15. On Day 16, the SEPM denies the update. On Day 17, the SEPM denies again... this will continue until Day 31 when the SEPM will assign new times to the clients. Even though this is an extreme example, you can see how this could make clients take a long time to get their updates. Even on a more reasonable 2-3 day distribution, a client could miss a number of consecutive update cycles.
An important note on the 'Distribute over X' feature: It sets an update timeframe for the clients. Once a client gets this time, it cannot be changed or reset. Example: Using the same 2 clients over 30 days... on Day 2 you realize 30 days was excessive and set it to distribute over 1 day. The second client has already been assigned to Day 15 and won't check for the new 1 day distribution until after Day 15. Note that these times are assigned by the SEPM and stored client-side. Once the client has a time, it will not check for updates until the timer is expired.
The Update Schedule (setting a window of time for updates to occur) has always been buggy. Even on the lastest builds, I've heard of people having trouble with clients that never upgrade as long as a schedule is set. The bug, as it was explained to me, is that the client will check-in and find the update schedule properly, but the bug makes it read the schedule as if it were for tomorrow. I don't know all the details, but I can say that removing the Schedule has worked for a lot of customers. It's worth noting that this bug doesn't happen all the time... sometimes clients update just fine... sometimes all but a few update... sometimes all but a few don't. YMMV, as they say.
Using the two features together yields even more interesting results. Assuming the schedule works, the 'Distribute over X' feature isn't aware of the schedule, so it sets updates to occur off-schedule. So your 5pm-5am window may never hit some clients, no matter how many times they go through the update process.
All-in-all, my recommendation is to not use either feature... or, at the most, use a smaller 'Distribute over X' time frame (2 days). If you're worried the SEPM will slam the network, look into throttling IIS. The client packages are served from the "ClientPackages" virtual directory and you can throttle it separate from the rest of the server to keep communication intact.
The other workaround, which is a lot more manual, is to create a sub-group with your Install Package setup to update clients that move into the group. Move batches of clients that haven't updated into the sub-group, let them update, move them back. For 15,000 clients, that's probably not a viable option (and not at all possible if you sync with AD), but for smaller environments, it can be an acceptable solution.