I'd like to hear more details about this, I heard some weird- recommendations on the forums and these changes are important to detail
Here is your answer:
https://forums.frontier.co.uk/threads/january-update-patch-notes.535051/post-8235583
I'd like to hear more details about this, I heard some weird- recommendations on the forums and these changes are important to detail
I have the same message now in PS4 ... shutdown in 10 minutes with 2.5 hours of mant.OK its back to 2.5hours on console..
9:30AM start.. end 12PM
[...]
We should all see a marked improvement for instancing, multicrew and FD server connects.
It won't help if you got a bizarro ISP.
[...]
Can you elaborate on that? How did you come to that conclusion.
At first glance this is about data compression, so Elite will need less bandwidth. But Elite hardly needs any anyway. Was this small amount already too much for AWS?
I think Elite's problem come from the fact that networking is hard and the P2P connections aren't very reliable. Would the inclusion of this library really magically fix a lot of that or is it just a "might as well" addition to save some bandwidth?
snip
They are down. Coming up in 2 hours.Is it possible to have the time of the update ? When do servers going to be down in UTC time ? or if you decide to postpone the update ? That ll be very nice.
Another question : I always have a captcha verification while logging to this forum ? Can we get of rid of this retardation process ? I m not fancy working for Google AI.
All ready posted, GB/UK time is UTC time, servers allready went down be back up ~12PM UTC..Is it possible to have the time of the update ? When do servers going to be down in UTC time ? or if you decide to postpone the update ? That ll be very nice.
Another question : I always have a captcha verification while logging to this forum ? Can we get of rid of this retardation process ? I m not fancy working for Google AI.
Not entirely true for Oodle (it is for naive compression, just compressing everything), because Oodle uses a time-space caching tradeoff. It ships a dictionary of pre-compressed snippets of data out to the client (few hundred KB, they say) and an index, so when they see a static element of a network packet that can be compressed, Oodle just swaps in the corresponding compressed snippet from the dictionary. Still costs some CPU, as well as a little memory and disk space, but the result is less data on the wire and that's apparently ED's bottleneck.Its compression technology for network traffic that has to be used on each client in the network...
Due to the compression the data bit rate needed are even lower on ISP and LAN connections... the negative is the processing extra task that the clients need to do...
On battery devices like mobiles or tablets this is a bad idea so is not popular... as ED is meant to be played on mains powered devices it don't realy matter...
We should all see a marked improvement for instancing, multicrew and FD server connects.
It won't help if you got a bizarro ISP.
Blogpost about Oodle, some good ideas using it, they might not still be relevant.
Oodle Network Usage Notes
Two things I thought to write down. 1. Oodle Network speed is very cache sensitive. Oodle Network uses a shared trained model. This ...cbloomrants.blogspot.com
How do you get them then? I tried verifying file integrity on steam and it only found 12 files for a total of 300MBs. That can't be the entire patch can it?More importantly the client updates are live for download as well.
1.2GB just for PS4 as example... For some in EU on ADSL that will take longer than the servers are down for...
How do you get them then? I tried verifying file integrity on steam and it only found 12 files for a total of 300MBs. That can't be the entire patch can it?
I have no idea why Elite is bottlenecking on data loads when the bandwidth monitor lists really small upload and download amounts, but I know that something is wrong there because streaming to discord causes desync/lag, and sometimes so does streaming music. I'm on a fiber optic gigabit connection so I don't think I should be bottlenecking on my end, but it sure acts like it is.Not entirely true for Oodle (it is for naive compression, just compressing everything), because Oodle uses a time-space caching tradeoff. It ships a dictionary of pre-compressed snippets of data out to the client (few hundred KB, they say) and an index, so when they see a static element of a network packet that can be compressed, Oodle just swaps in the corresponding compressed snippet from the dictionary. Still costs some CPU, as well as a little memory and disk space, but the result is less data on the wire and that's apparently ED's bottleneck.
I guess FD (well, hchalkley at least ) know what their network protocols' data looks like and can recognise where this kind of compression is relevant, eg not on Cmdr mugshot jpegs (one would hope those are transmitted as ~64 bytes of face parameters and rendered locally, but I am rarely surprised these days) or gzipped Galnet article text.
It's been a while (since Alpha/Premium Beta) since I had a close look at things, but the dictionary approach says to me that Oodle works best where the wire data is human readable or not already highly optimised and tends to contain repetitive static blocks (think most of a web app's HTTP headers, or all the bits of rfc822 email headers that are in every email ever sent). The last time I peeked at the P2P protocol, it was already fairly tight, because it has been written to be as robust as possible in the face of all the horrid kinds of MTU limits and NAT ISPs deploy.
Where I suspect it will save bandwidth is the mission boards, market data, selling exploration data and fetching the non PG parts of stellarforge systems, which seem like the most bandwidth sensitive parts these days.