| Pages: 1 [2] :: one page |
|
|
| Author |
Thread Statistics | Show CCP posts - 4 post(s) |
|
ISD Stephan Lau
ISD Interstellar Correspondents
   |
Posted - 2010.12.07 20:58:00 -
[31]
 Originally by: BeanBagKing
Originally by: ISD Stephan Lau
if you feel that you can bring a more appropriate word to the table...
Ignoring OP and quoting the important part, someone above already has, and players seem to agree it's the most epic "RP" description of lag ever made. I hope you take it under consideration. People shouldn't have to apply to a full ISD position to make a single useful contribution.
In regards to Culmen's post, the ideas and terminology have already been noted and passed on to senior IC staff for discussion.
~ Stephan Lau
|
|
Falcus Hadron
|
Posted - 2010.12.07 21:00:00 -
[32]
Edited by: Falcus Hadron on 07/12/2010 21:01:31
So lag is now RP?
Sweet!
What next...writing off the t20 scandal or moon goo duplication?
|
Culmen
Caldari
Blood Phage Syndicate
|
Posted - 2010.12.07 21:00:00 -
[33]
Edited by: Culmen on 07/12/2010 21:05:19
Originally by: ISD Stephan Lau
Originally by: BeanBagKing
Originally by: ISD Stephan Lau
if you feel that you can bring a more appropriate word to the table...
Ignoring OP and quoting the important part, someone above already has, and players seem to agree it's the most epic "RP" description of lag ever made. I hope you take it under consideration. People shouldn't have to apply to a full ISD position to make a single useful contribution.
In regards to Culmen's post, the ideas and terminology have already been noted and passed on to senior IC staff for discussion.
~ Stephan Lau
Thanks.
If you want I can write up a more detail analysis.
This was 5 minutes of writing up some technobabble with stuff that's been bouncing around my head for a while.
and further more why do i even need a sig? |
|
ISD Stephan Lau
ISD Interstellar Correspondents
|
Posted - 2010.12.07 21:12:00 -
[34]
Originally by: Culmen
Edited by: Culmen on 07/12/2010 21:05:19
Originally by: ISD Stephan Lau
Originally by: BeanBagKing
Originally by: ISD Stephan Lau
if you feel that you can bring a more appropriate word to the table...
Ignoring OP and quoting the important part, someone above already has, and players seem to agree it's the most epic "RP" description of lag ever made. I hope you take it under consideration. People shouldn't have to apply to a full ISD position to make a single useful contribution.
In regards to Culmen's post, the ideas and terminology have already been noted and passed on to senior IC staff for discussion.
~ Stephan Lau
Thanks.
If you want I can write up a more detail analysis.
This was 5 minutes of writing up some technobabble with stuff that's been bouncing around my head for a while.
By all means, any suggestions on this matter are welcomed.
you contact me at [email protected]
Likwise I am also only an EvE mail away in-game
~ Stephan Lau
|
|
JC Anderson
Caldari
Noir.
Noir. Mercenary Group
|
Posted - 2010.12.07 21:43:00 -
[35]
Edited by: JC Anderson on 07/12/2010 21:44:24
Originally by: Falcus Hadron
Edited by: Falcus Hadron on 07/12/2010 21:01:31
So lag is now RP?
Sweet!
What next...writing off the t20 scandal or moon goo duplication?
Nobody ever said lag is rp.
The correspondents are volunteers that are bound by numerous rules when it comes to their jobs. The main being that they are required to remain in character while writing news stories or while in-game under the ic guise.
If they are covering a story where outside technical issues caused problems, they are required to come up with an in-character way of describing it. Be it lag, or a cluster crash, or even people going link dead in the middle of a battle.
They can't simply say "lag" because that is not something that could be translated into the eve universe from an rp perspective. Blaming them for this doesn't make much sense when the sole purpose of the ic is to write news from an in-character rp standpoint. It's not all that easy to translate bugs and technical issues into something that makes sense within the boundaries of the eve universe, and yet they are required to do so for our benefit.
|
PhoenixDawn
Gallente
Forge Regional Security
United Corporations Of Modern Eve
|
Posted - 2010.12.07 21:48:00 -
[36]
In regards to Culmen's impressive technobabble, let us understand just how quantum entanglement works in a communication network model.
Essentially, it has three points:
Transmitter -> central data transfer system -> target.
Each ship (station, planet, pocket comm) has one half of its quantum entangled data package, which is pretty doggone small. 100 thousand quantum bits and a reader in a package about the size of a pocket phone. To make a call of 1 mile or 1 thousand light years uses the same methodology.
The sender initiates communication to a target or area of targets (wingman, fleet, local, ect). That data is fed through the quantum pool and, at the same exact moment, is read by a massive (TRULY massive, comprising an entire planetary system) relay center. In our example let's say it's Yulai. The relay center decompiles the data, determines its routing, transmits it to the requisite local halves of every quantum pool the initiator was sending to, and the data is simultaneously read by the target comms devices.
The only appreciable delay occurs at the relay system which would require its own huge quantum coupled transmitter between discreet relay locations during the period of data routing.
Now, in the situation with your massive fleet engaging in an epic battle, so much data is being pumped into a single data transfer node at the Relay that it simply cannot regurgitate it out fast enough to keep up with the flow of data. Coupled with the local Ansible instability this results in a data glut that blinds pretty much every ship in a given locale.
Sensors are the first to go, then point to point comms. Without incoming sensor data ships start shutting down systems, or their local computational arrays become overwhelmed by the Relay flood and cease to operate.
Secondary slower-than-lightspeed communication methods may still work (ship-to-ship voice comms) due to relatively low complexity increasing reliability.
|
|
|
| |
|
| Pages: 1 [2] :: one page |
| First page | Previous page | Next page | Last page |