Cài đặt Steam
Đăng nhập
|
Ngôn ngữ
简体中文 (Hán giản thể)
繁體中文 (Hán phồn thể)
日本語 (Nhật)
한국어 (Hàn Quốc)
ไทย (Thái)
Български (Bungari)
Čeština (CH Séc)
Dansk (Đan Mạch)
Deutsch (Đức)
English (Anh)
Español - España (Tây Ban Nha - TBN)
Español - Latinoamérica (Tây Ban Nha cho Mỹ Latin)
Ελληνικά (Hy Lạp)
Français (Pháp)
Italiano (Ý)
Bahasa Indonesia (tiếng Indonesia)
Magyar (Hungary)
Nederlands (Hà Lan)
Norsk (Na Uy)
Polski (Ba Lan)
Português (Tiếng Bồ Đào Nha - BĐN)
Português - Brasil (Bồ Đào Nha - Brazil)
Română (Rumani)
Русский (Nga)
Suomi (Phần Lan)
Svenska (Thụy Điển)
Türkçe (Thổ Nhĩ Kỳ)
Українська (Ukraine)
Báo cáo lỗi dịch thuật
Do you happen to run any LSP software, or network speed boosters ?
] peer_content_server_status
Peer content server status (1 connections):
- chunks : 0 pending, 0 total sent, 8 total requested
- bytes : 0 bytes read from disk at 0 bytes/sec, 0 bytes sent via network at 0 bytes/sec
- TCP : 0 oustanding sends (0 bytes)
] peer_content_server_status
Peer content server status (1 connections):
- chunks : 0 pending, 0 total sent, 8 total requested
- bytes : 0 bytes read from disk at 0 bytes/sec, 0 bytes sent via network at 0 bytes/sec
- TCP : 0 oustanding sends (0 bytes)
] peer_content_server_status
Peer content server status (1 connections):
- chunks : 0 pending, 0 total sent, 8 total requested
- bytes : 0 bytes read from disk at 0 bytes/sec, 0 bytes sent via network at 0 bytes/sec
- TCP : 0 oustanding sends (0 bytes)
weirdly enough it was saying 0 during different times of the test :D
Tested again with a 50gb game and got some bits of info
] peer_content_server_status
Peer content server status (1 connections):
- chunks : 2 pending, 509 total sent, 511 total requested
- bytes : 520.58 MB read from disk at 36.88 MB/sec, 519.33 MB sent via network at 36.94 MB/sec
- TCP : 173 oustanding sends (173.52 MB)
] peer_content_server_status
Peer content server status (1 connections):
- chunks : 3 pending, 611 total sent, 614 total requested
- bytes : 626.31 MB read from disk at 36.10 MB/sec, 624.85 MB sent via network at 36.09 MB/sec
- TCP : 175 oustanding sends (179.43 MB)
] peer_content_server_status
Peer content server status (1 connections):
- chunks : 3 pending, 670 total sent, 673 total requested
- bytes : 686.73 MB read from disk at 36.56 MB/sec, 685.10 MB sent via network at 36.52 MB/sec
- TCP : 179 oustanding sends (184.52 MB)
No LSP software or speed booster on this machine (fresh windows install)
It's needlessly bottlenecking the entire transfer process on either of my CPUs (3700X/5600X/8700) by quite a huge margin (i.e. 700Mbps top vs 1GBps networking layer)
iperf3 log from desktop (desktop `iperf3 -s`, Deck `iperf3 -c <desktop> -R`)
Some other things to note, my host pc would not transfer while downloading a update, or another game. Also if u have multiple pc's you might want to check and see which pc it is choosing to transfer from. If you check on the pc on steam downloads page it will show that it is hosting a file transfer.
- PC: Downloaded game, Win7 x64, 1 Gbit ethernet
- Laptop: Download started and paused, Wi-Fi (up to ~600-800 Mbps)
1. Opt-in to Beta, restart
2. Upon starting, the P2P download started automatically (I did NOT resume the download, well... OK. It's a design decision)
3. The PC fans are revving up. Up to 50% total CPU consumption → full 8 physical cores loaded. Ryzen 7 1700 @ 3.8 GHz OC. Turns out it's transferring the game data!
4. The laptop load equates to 2 full threads loaded.
5. The wifi bandwidth traffic jumped up and down.
This to me looks very much like insane compression presets on the host, otherwise the CPU load cannot be explained. Two questions:
1. If it's compression, why isn't ZSTD being used? It's one of the fastest algorithms out there with more than just acceptable performance.
2. If compression's being used, are compressed game assets archives being compressed again? This can be avoided by analyzing file extensions on the first encounter for whether
a) they are in a known archive format
OR
b) the entropy analysis indicates the data is random enough to be considered compressed (chi-squared test)
In other words, on the first pass the reader compresses by default but also runs the evaluation test. If the file extension looks to have random data (=compressed) then the next files of this same extension will NOT be compressed for p2p transfer.
It's making this function essentially useless for most people by default.
Let alone that neither 5600X, nor 3700X or 8700 are fast enough to compress files on fly for 10Gb networking, so it is even more useless for me.
I have a spare machine with 4x 1Gbit LAN card with link aggregation, so it should be able to serve the full 4Gbit to 4 machines pulling it at 1Gbit/s. But the CPU bottomed out at about 80MB/s total for all machines.
I understand this is not the intended purpose for the feature, and still think it's a great feature, no complaints. But if it's somehow possible to turn off the compression for local transfers, that would be great.
I ended up making a local fileshare on the server, simply sharing the steamapps folder. Then copying the files to the target machines using Windows filesharing. It nicely pulled 2.5Gbit over 3 machines copying simultaneously. Much faster than the 80MB/s I was getting with local transfers, also with negligible CPU usage on the server. After copying files to clients, simply hit the install button, and it verifies local files and installs games.
Tested between two moderately powerful PCs with ssd drives on wired ethernet, one with 2.5Gb/s and the other with 1Gb/s with 10Gb capable switches in between. Iperf caps out at 986Mb/s, but i'm only seeing about 150mb/s via the steam lan transfer. (there's a *very* short 250Mb/s peak at the start, but then it drops off a cliff.
Last night transferring borderlands 3 I saw 4 cores on the Host pc are capped out at 100% by the shader pregen, but the rest of the cpu is completely idle, and aside from that one example, the host and the Client CPUs are both sitting at ~30% across all cores. (testing with Satisfactory right now, and there is *no* CPU or IO bottleneck on either machine.)
Personally, my best guess is that it's a quickly hashed out repurpose of the Remote Play pipeline, which you'd obviously need compression in, and stripping that step out was missed in the code surgery.
My home network is full gigabit ethernet and I have a WiFi 6 network via a Unifi AP (though Unifi is showing the Steam Deck connected over WiFi 5 on a 5Ghz channel). Not that it particularly matters in this case, but I have gigabit fiber.
I've run iperf3 between various computers on the network, Wired-to-Wired and Wired-to-WiFi and the reported speeds there are all within expectations. So for internal Steam transfers running as slow as they are -- slower than even Internet downloads -- seems strange.