User talk:Zac67
Archives (Index) |
This page is archived by ClueBot III.
|
Vandalism
I issue you a warning for vandalism in the article PCI Express. You are canceling data verified by authoritative and independent sources, while you yourself are guided by WP:OR. This is not allowed and violates wikipedia rules WP:RS --185.52.142.168 (talk) 08:14, 10 August 2023 (UTC)
- You are being ignorant. You obviously haven't read my comments and that the article clearly says that the throughputs are per direction and that PCI SIG and various, copying sources show aggregate throughput for Tx and Rx which doubles the values. If you want to change the article accordingly, you'll need to take it to the talk page. In the meantime, please stop reverting to incorrect figures. --Zac67 (talk) 09:06, 10 August 2023 (UTC)
- Am I being ignorant? Am I deleting data confirmed by sources?! Or are you doing this? Did you read my edit comments yourself? Have you been able to object to at least one argumentatively instead of rude reversals of edits? My figures, as you say, are confirmed by relevant sources, but how do you confirm your numbers?! You are doing original research in gross violation of the WP:OR rule. For the phrase "PCI SIG and various, copying sources show aggregate throughput for Tx and Rx which doubles the values" provide independent sources? I hear this from you, and I repeat, Wikipedia is written not from the words of the participants, but according to data from sources! If the source says that for 7.0 x16 the speed is 512 GB / s, then this is exactly what we indicate on Wikipedia, without any original research! --185.52.142.168 (talk) 12:42, 10 August 2023 (UTC)
- Have you even read your own sources??
- --Zac67 (talk) 14:21, 10 August 2023 (UTC)
- Personally, I don't have to prove anything. You must justify your edits with these sources, and put them in the article itself, as I do. --185.52.142.168 (talk) 15:02, 10 August 2023 (UTC)
- Am I being ignorant? Am I deleting data confirmed by sources?! Or are you doing this? Did you read my edit comments yourself? Have you been able to object to at least one argumentatively instead of rude reversals of edits? My figures, as you say, are confirmed by relevant sources, but how do you confirm your numbers?! You are doing original research in gross violation of the WP:OR rule. For the phrase "PCI SIG and various, copying sources show aggregate throughput for Tx and Rx which doubles the values" provide independent sources? I hear this from you, and I repeat, Wikipedia is written not from the words of the participants, but according to data from sources! If the source says that for 7.0 x16 the speed is 512 GB / s, then this is exactly what we indicate on Wikipedia, without any original research! --185.52.142.168 (talk) 12:42, 10 August 2023 (UTC)
I will no longer deal with the war of edits, but I believe that you are wrong! A significant majority of sources, including PCI-SIG itself, use the speed indication in bi-directionally, so why do you think that we, violating the rule WP: OR, should indicate the speed in one stream? If in the sources the speed is indicated in both directions, then we must indicate this. --185.52.142.168 (talk) 15:29, 10 August 2023 (UTC)
Fragment Free Switching
Hi,Zac67, sorry for writing here, I read an answer of yours on "Stack Exchange", but for some reason I don't know I cannot create a count and login "Stack Exchange", but I'm really want to get some help from you about the fragment free switching mechanism(please excuse me for my silly question, I'm a new guy for ethernet, and learning and testing about the switching mechanism).On "Stack Exchange"([5]https://networkengineering.stackexchange.com/questions/60049/what-exactly-is-fragment-free-switching), you mentioned". There is no integrity check for the first 64 bytes in Ethernet. On L2, there's only FCS for the whole frame, nothing else. Depending on the actual L1 PHY, there may be additional PCS level checks or FEC, but these are on line symbols or code groups. For IPv4 (L3) there's an IP header checksum that falls into the first 64 bytes, but IPv6 and other L3 protocols don't have that. Some transport-layer protocols (L4) also use header checksums but those differ as well. – Zac67♦ Jun 26, 2019 at 17:13 ", So my question is if a fragment free switch reviewed a frame more than 64 bytes(e.g. 128bytes), but with a CRC error, then what will be the behavior of the switch? To my understanding, the switch will forward the frame, until it monitored that there is a "CRC Error", that means the switch will "cut off" a part of the frame, and forward a part of the frame, am I right? And for the forwarded frame, is there a "CRC" 4 bytes in it? As a results of my test, there is a CRC on in the forwarded frame, and it is a Error CRC, that makes me confuse. I hope I didn't disturb you and hope to receive your reply. Best Regards 111.118.203.20 (talk) 01:55, 29 August 2023 (UTC)
- I don't think this is the right place, but in short: in cut-through mode the switch has already started forwarding and the FCS hasn't been received yet. When the FCS is received it's too late to stop forwarding, so the frame is forwarded in full, including the bad FCS. In store-and-forward mode (with a previous FCS error rate above a certain threshold) the frame is dropped for failing FCS check. --Zac67 (talk) 07:01, 29 August 2023 (UTC)
- Thank you so much for your reply. Yes, I think the "cut-though" mode is just like what you said, but what about "fragment free"? To my understanding, it is between "store forward" and "cut-though", "fragment free" will check the received frame to make sure it is not a runt frame, and then forward it, and what if the switch received a normal size frame(more than 64B) but with a bad CRC, will the switch cut off a part of the frame? Or the switch will be just like "cut-though" mode? 111.118.203.24 (talk) 01:29, 30 August 2023 (UTC)
- Short follow up: I've tried to find out whether SE blocks account creation per IP address but couldn't find that. Perhaps it's the Great Firewall blocking you. --Zac67 (talk) 16:55, 29 August 2023 (UTC)
- Yes, maybe that's the reason.:/
- Thanks again and holp I didn't bother you too much. 111.118.203.24 (talk) 01:31, 30 August 2023 (UTC)
Numbers in table
I would like you to reconsider this undo [1] of the edit I did to the layers table.
WP:NUMBERS recommends "In tables and infoboxes, quantities are expressed in figures (Years in office: 5); but numbers within a table's explanatory text and comments follow the general rule." The number of layers also fit with the number-unit pattern (3 layers) for which it WP:NUMBERS also recommends using figures rather than text.
These recommendations coincide with the general view of the people I have asked about what table is clearer. So I would be very happy if you could reapply the changes. Thank you. Arauzo (talk) 11:33, 12 September 2023 (UTC)
[1] https://en.wikipedia.org/w/index.php?title=Internet_protocol_suite&oldid=prev&diff=1163791422 Arauzo (talk) 11:32, 12 September 2023 (UTC)
- The current use in that table does not represent the "Years in office: 5" pattern you quote, but rather "5 years in office" versus "five years in office". To me, the latter appears more readable, in line with the MOS's comment-in-table variant. We could change the table to feature a row header "number of layers" which would then reasonably dictate the use numerals within the table instead of words. I'd prefer not to, however. Any which way, this is not the right place for that discussion but it's rather here. --Zac67 (talk) 12:34, 12 September 2023 (UTC)
Parallel routes for a single session
AKAIK usings different paths for consecutive datagrams of a given user session MUST be avoided in the Internet. (TCP doens't like frequent packet permutations with substantially different delays. They can be taken for packet losses and cause cause inappropriate retransmissions). Unless you know real networks that ignore this constraint (which ones?), I respectfully suggest that my wording is more instructive (and avoids being misleading on how the Internet works).RD2017 (talk) 15:45, 17 October 2023 (UTC)