Forums online, news to follow


Recommended Posts

Happy with the new Host ?

Think I saw Neobond say the old host where charging Neowin for extra bandwidth used.

No, I'm personally not. This is on a Cogent powered network. You will notice slower network transfer speeds and higher latency because it's a cheaper provider. The frigging connection between Dallas and Chicago was only 180Kb/s! What the hell is that?

On the upside, there's a bit better hardware available to us now and the codebase is up to the latest version, which has some things that should stop a lot of the freezing that was happening in MySQL before.

Also, I fixed the sync between the two webserver filesystems. I think we'll have to add another webserver soon and then start thinking about MySQL clustering (which gets interesting, to say the least...). These new servers are nice, but there's always room for Jello!

Actually, I'm curious to see how much slower the connection is for everyone. Can you ping these two addresses and post the results? 63.28.242.201 and 67.19.42.49

Should look like this:

Pinging 67.19.42.49 with 32 bytes of data:

Reply from 67.19.42.49: bytes=32 time=25ms TTL=242
Reply from 67.19.42.49: bytes=32 time=24ms TTL=242
Reply from 67.19.42.49: bytes=32 time=24ms TTL=242
Reply from 67.19.42.49: bytes=32 time=23ms TTL=242

Ping statistics for 67.19.42.49:
	Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
	Minimum = 23ms, Maximum = 25ms, Average = 24ms

inging 66.28.242.201 with 32 bytes of data:

eply from 66.28.242.201: bytes=32 time=56ms TTL=109
eply from 66.28.242.201: bytes=32 time=58ms TTL=109
eply from 66.28.242.201: bytes=32 time=57ms TTL=109
eply from 66.28.242.201: bytes=32 time=57ms TTL=109

ing statistics for 66.28.242.201:
   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
pproximate round trip times in milli-seconds:
   Minimum = 56ms, Maximum = 58ms, Average = 57ms

Hmm.. :/

ping 63.28.242.201

Pinging 63.28.242.201 with 32 bytes of data:

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Ping statistics for 63.28.242.201:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

ping 67.19.41.49

Pinging 67.19.41.49 with 32 bytes of data:

Reply from 67.19.41.49: bytes=32 time=166ms TTL=241

Reply from 67.19.41.49: bytes=32 time=171ms TTL=241

Reply from 67.19.41.49: bytes=32 time=281ms TTL=241

Reply from 67.19.41.49: bytes=32 time=187ms TTL=241

Ping statistics for 67.19.41.49:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 166ms, Maximum = 281ms, Average = 201ms

Pinging 66.28.242.201 with 32 bytes of data:

Reply from 66.28.242.201: bytes=32 time=326ms TTL=115

Reply from 66.28.242.201: bytes=32 time=324ms TTL=115

Reply from 66.28.242.201: bytes=32 time=323ms TTL=115

Reply from 66.28.242.201: bytes=32 time=327ms TTL=115

Ping statistics for 66.28.242.201:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss

Approximate round trip times in milli-seconds:

Minimum = 323ms, Maximum = 327ms, Average = 325ms

Reply from 67.19.42.49: bytes=32 time=343ms TTL=239

Reply from 67.19.42.49: bytes=32 time=393ms TTL=239

Reply from 67.19.42.49: bytes=32 time=342ms TTL=239

Reply from 67.19.42.49: bytes=32 time=362ms TTL=239

Ping statistics for 67.19.42.49:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 342ms, Maximum = 393ms, Average = 360ms

No, I'm personally not. This is on a Cogent powered network. You will notice slower network transfer speeds and higher latency because it's a cheaper provider. The frigging connection between Dallas and Chicago was only 180Kb/s! What the hell is that?

On the upside, there's a bit better hardware available to us now and the codebase is up to the latest version, which has some things that should stop a lot of the freezing that was happening in MySQL before.

Also, I fixed the sync between the two webserver filesystems. I think we'll have to add another webserver soon and then start thinking about MySQL clustering (which gets interesting, to say the least...). These new servers are nice, but there's always room for Jello!

Actually, I'm curious to see how much slower the connection is for everyone. Can you ping these two addresses and post the results? 63.28.242.201 and 67.19.42.49

Should look like this:

Pinging 67.19.42.49 with 32 bytes of data:

Reply from 67.19.42.49: bytes=32 time=25ms TTL=242
Reply from 67.19.42.49: bytes=32 time=24ms TTL=242
Reply from 67.19.42.49: bytes=32 time=24ms TTL=242
Reply from 67.19.42.49: bytes=32 time=23ms TTL=242

Ping statistics for 67.19.42.49:
	Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
	Minimum = 23ms, Maximum = 25ms, Average = 24ms

inging 66.28.242.201 with 32 bytes of data:

eply from 66.28.242.201: bytes=32 time=56ms TTL=109
eply from 66.28.242.201: bytes=32 time=58ms TTL=109
eply from 66.28.242.201: bytes=32 time=57ms TTL=109
eply from 66.28.242.201: bytes=32 time=57ms TTL=109

ing statistics for 66.28.242.201:
   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
pproximate round trip times in milli-seconds:
   Minimum = 56ms, Maximum = 58ms, Average = 57ms

Did you mean 66.28.242.201 and not 63.28.242.201, because I get Request Timed Out on 63.28.242.201, and I noticed you used 66.28.242.201 in your ping results. :p

Anyway, here are my results.

Pinging 66.28.242.201 with 32 bytes of data:

Reply from 66.28.242.201: bytes=32 time=57ms TTL=238
Reply from 66.28.242.201: bytes=32 time=97ms TTL=238
Reply from 66.28.242.201: bytes=32 time=156ms TTL=238
Reply from 66.28.242.201: bytes=32 time=45ms TTL=238

Ping statistics for 66.28.242.201:
   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
   Minimum = 45ms, Maximum = 156ms, Average = 88ms

Pinging 67.19.42.49 with 32 bytes of data:

Reply from 67.19.42.49: bytes=32 time=46ms TTL=238
Reply from 67.19.42.49: bytes=32 time=135ms TTL=238
Reply from 67.19.42.49: bytes=32 time=46ms TTL=238
Reply from 67.19.42.49: bytes=32 time=46ms TTL=238

Ping statistics for 67.19.42.49:
   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
   Minimum = 46ms, Maximum = 135ms, Average = 68ms

Heh. I woke up to find Neowin still on my computer screen. (it was a thread I left open. lol. I closed it and re-open it to get fresh tthreads or news but got told the servers were down. lol.

btw I am now known as ozgeek, not mr.roberts. (ozgeek stands for Australian geek).

and timdorr how do I ping for you? is it ping via cmd?

Hmmm... I can go to neowin.net/forum, yet all the links inside point to neowin5.net/forum/whatever... Kind of strange... Is this still a result of the DNS servers or what?

Hey I just noticed that now I know how many stars I have to go to reach the end :D Just 3 left...

Mine ...

Pinging 67.19.42.49 with 32 bytes of data:

Reply from 67.19.42.49: bytes=32 time=179ms TTL=239

Reply from 67.19.42.49: bytes=32 time=180ms TTL=239

Reply from 67.19.42.49: bytes=32 time=189ms TTL=239

Reply from 67.19.42.49: bytes=32 time=179ms TTL=239

Ping statistics for 67.19.42.49:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 179ms, Maximum = 189ms, Average = 181ms

Pinging 66.28.242.201 with 32 bytes of data:

Reply from 66.28.242.201: bytes=32 time=167ms TTL=112

Reply from 66.28.242.201: bytes=32 time=167ms TTL=112

Reply from 66.28.242.201: bytes=32 time=165ms TTL=112

Reply from 66.28.242.201: bytes=32 time=167ms TTL=112

Ping statistics for 66.28.242.201:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 165ms, Maximum = 167ms, Average = 166ms

Reply from 67.19.42.49: bytes=32 time=131ms TTL=236
Reply from 67.19.42.49: bytes=32 time=123ms TTL=236
Reply from 67.19.42.49: bytes=32 time=123ms TTL=237
Reply from 67.19.42.49: bytes=32 time=126ms TTL=237

Ping statistics for 67.19.42.49:
	Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
	Minimum = 123ms, Maximum = 131ms, Average = 125ms


Pinging 66.28.242.201 with 32 bytes of data:

Reply from 66.28.242.201: bytes=32 time=120ms TTL=113
Reply from 66.28.242.201: bytes=32 time=120ms TTL=113
Reply from 66.28.242.201: bytes=32 time=121ms TTL=113
Reply from 66.28.242.201: bytes=32 time=122ms TTL=113

Ping statistics for 66.28.242.201:
	Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
	Minimum = 120ms, Maximum = 122ms, Average = 120ms

Last login: Tue Nov 29 20:55:27 on ttyp1

Welcome to Darwin!

nicholas-pachecos-mac-mini:~ Nicholas$ ping 67.19.42.49

PING 67.19.42.49 (67.19.42.49): 56 data bytes

64 bytes from 67.19.42.49: icmp_seq=0 ttl=241 time=49.703 ms

64 bytes from 67.19.42.49: icmp_seq=1 ttl=241 time=59.904 ms

64 bytes from 67.19.42.49: icmp_seq=2 ttl=241 time=84.557 ms

64 bytes from 67.19.42.49: icmp_seq=3 ttl=241 time=47.258 ms

64 bytes from 67.19.42.49: icmp_seq=4 ttl=241 time=48.742 ms

64 bytes from 67.19.42.49: icmp_seq=5 ttl=241 time=52.378 ms

^C

--- 67.19.42.49 ping statistics ---

6 packets transmitted, 6 packets received, 0% packet loss

round-trip min/avg/max/stddev = 47.258/57.090/84.557/12.945 ms

nicholas-pachecos-mac-mini:~ Nicholas$

Pinging 67.19.42.49 with 32 bytes of data:

Reply from 67.19.42.49: bytes=32 time=102ms TTL=243
Reply from 67.19.42.49: bytes=32 time=100ms TTL=243
Reply from 67.19.42.49: bytes=32 time=96ms TTL=243
Reply from 67.19.42.49: bytes=32 time=100ms TTL=243

Ping statistics for 67.19.42.49:
	Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
	Minimum = 96ms, Maximum = 102ms, Average = 99ms 

Pinging 66.28.242.201 with 32 bytes of data:

Reply from 66.28.242.201: bytes=32 time=115ms TTL=105
Reply from 66.28.242.201: bytes=32 time=130ms TTL=105
Reply from 66.28.242.201: bytes=32 time=114ms TTL=105
Reply from 66.28.242.201: bytes=32 time=114ms TTL=105

Ping statistics for 66.28.242.201:
	Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
	Minimum = 114ms, Maximum = 130ms, Average = 118ms

No, I'm personally not. This is on a Cogent powered network. You will notice slower network transfer speeds and higher latency because it's a cheaper provider. The frigging connection between Dallas and Chicago was only 180Kb/s! What the hell is that?

On the upside, there's a bit better hardware available to us now and the codebase is up to the latest version, which has some things that should stop a lot of the freezing that was happening in MySQL before.

Also, I fixed the sync between the two webserver filesystems. I think we'll have to add another webserver soon and then start thinking about MySQL clustering (which gets interesting, to say the least...). These new servers are nice, but there's always room for Jello!

Actually, I'm curious to see how much slower the connection is for everyone. Can you ping these two addresses and post the results? 63.28.242.201 and 67.19.42.49

Timdorr, Other than ping time the thing interests me is the number of hops inside the network look at the number of hops once I get inside the cogentco network.

traceroute to neowin.net (66.28.242.203), 30 hops max, 40 byte packets
 1  vlan250.lon-service6.Melbourne.telstra.net (203.50.2.177)  0.335 ms  0.202 ms  0.258 ms
 2  10GigabitEthernet9-0.win-core1.Melbourne.telstra.net (203.50.79.129)  0.357 ms  0.389 ms  0.259 ms
 3  Pos-Channel2.ken-core4.Sydney.telstra.net (203.50.6.21)  12.936 ms  12.972 ms  12.984 ms
 4  10GigabitEthernet3-0.pad-core4.Sydney.telstra.net (203.50.6.86)  32.545 ms  12.983 ms  12.982 ms
 5  10GigabitEthernet2-2.syd-core02.Sydney.net.reach.com (203.50.13.42)  13.234 ms  13.208 ms  13.17 ms
 6  i-0-0.wil-core02.net.reach.com (202.84.144.101)  161.363 ms  161.335 ms  161.353 ms
 7  unknown.net.reach.com (202.84.251.166)  160.962 ms  160.91 ms  160.872 ms
 8  unassign.net.reach.com (134.159.63.66)  160.952 ms  160.934 ms  160.844 ms
 9  p6-0.core01.lax01.atlas.cogentco.com (154.54.2.209)  162.04 ms  162.152 ms  162.201 ms
10  p5-0.core01.san01.atlas.cogentco.com (66.28.4.78)  163.916 ms  163.649 ms  163.72 ms
11  p6-0.core01.iah01.atlas.cogentco.com (66.28.4.5)  195.383 ms  195.381 ms  195.81 ms
12  p13-0.core01.mci01.atlas.cogentco.com (66.28.4.106)  223.775 ms  223.66 ms  223.736 ms
13  p5-0.core02.ord01.atlas.cogentco.com (66.28.4.34)  234.876 ms  235.536 ms  234.794 ms
14  p12-0.core03.ord01.atlas.cogentco.com (154.54.3.154)  234.369 ms  234.337 ms  234.413 ms
15  p2-0.core01.ord04.atlas.cogentco.com (154.54.3.42)  235.05 ms  234.902 ms  234.985 ms
16  g3-1.hc01.ord04.atlas.cogentco.com (204.6.150.30)  234.651 ms  234.532 ms  234.636 ms
17  StardockCorporation.demarc.cogentco.com (38.112.15.250)  234.951 ms  234.965 ms  235.292 ms
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Here's my ping times:

Reply from 67.19.42.49: bytes=32 time=42ms TTL=244

Reply from 67.19.42.49: bytes=32 time=42ms TTL=244

Reply from 67.19.42.49: bytes=32 time=42ms TTL=244

Reply from 67.19.42.49: bytes=32 time=42ms TTL=244

Ping statistics for 67.19.42.49:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 42ms, Maximum = 42ms, Average = 42ms

and

Pinging 66.28.242.201 with 32 bytes of data:

Reply from 66.28.242.201: bytes=32 time=69ms TTL=114

Reply from 66.28.242.201: bytes=32 time=158ms TTL=114

Reply from 66.28.242.201: bytes=32 time=144ms TTL=114

Reply from 66.28.242.201: bytes=32 time=70ms TTL=114

Ping statistics for 66.28.242.201:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 69ms, Maximum = 158ms, Average = 110ms

That second server's not as fast to respond...

Pinging 67.19.42.49 with 32 bytes of data:

Reply from 67.19.42.49: bytes=32 time=115ms TTL=233

Reply from 67.19.42.49: bytes=32 time=129ms TTL=233

Reply from 67.19.42.49: bytes=32 time=127ms TTL=233

Reply from 67.19.42.49: bytes=32 time=116ms TTL=232

Ping statistics for 67.19.42.49:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 115ms, Maximum = 129ms, Average = 121ms

Pinging 66.28.242.201 with 32 bytes of data:

Reply from 66.28.242.201: bytes=32 time=123ms TTL=107

Reply from 66.28.242.201: bytes=32 time=123ms TTL=107

Reply from 66.28.242.201: bytes=32 time=124ms TTL=107

Reply from 66.28.242.201: bytes=32 time=123ms TTL=107

Ping statistics for 66.28.242.201:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 123ms, Maximum = 124ms, Average = 123ms

Pretty adverage ping times for me.

Keep up all the good work <3

Whoops, yep, I meant 66.28.242.201. Sorry about that. Just curious, though. No biggie :)

and for that IP still a lot of hops insde that network

traceroute to 66.28.242.201 (66.28.242.201), 30 hops max, 40 byte packets
 1  vlan250.lon-service6.Melbourne.telstra.net (203.50.2.177)  0.339 ms  0.358 ms  0.24 ms
 2  10GigabitEthernet9-0.win-core1.Melbourne.telstra.net (203.50.79.129)  0.341 ms  0.281 ms  0.389 ms
 3  Pos-Channel2.ken-core4.Sydney.telstra.net (203.50.6.21)  13.067 ms  12.866 ms  12.965 ms
 4  10GigabitEthernet3-0.pad-core4.Sydney.telstra.net (203.50.6.86)  12.923 ms  13.025 ms  12.967 ms
 5  10GigabitEthernet2-2.syd-core02.Sydney.net.reach.com (203.50.13.42)  13.213 ms  13.205 ms  13.21 ms
 6  i-0-0.wil-core02.net.reach.com (202.84.144.101)  161.414 ms  161.362 ms  161.34 ms
 7  unknown.net.reach.com (202.84.251.166)  246.252 ms  160.911 ms  160.839 ms
 8  unassign.net.reach.com (134.159.63.66)  160.858 ms  160.93 ms  160.977 ms
 9  p15-0.core01.lax01.atlas.cogentco.com (154.54.2.213)  161.429 ms  161.372 ms  161.707 ms
10  p5-0.core01.san01.atlas.cogentco.com (66.28.4.78)  163.94 ms  163.584 ms  163.764 ms
11  p6-0.core01.iah01.atlas.cogentco.com (66.28.4.5)  195.505 ms  196.641 ms  195.494 ms
12  p13-0.core01.mci01.atlas.cogentco.com (66.28.4.106)  223.754 ms  223.725 ms  223.642 ms
13  p5-0.core02.ord01.atlas.cogentco.com (66.28.4.34)  235.219 ms  234.752 ms  234.889 ms
14  p12-0.core03.ord01.atlas.cogentco.com (154.54.3.154)  234.494 ms  234.479 ms  234.522 ms
15  p2-0.core01.ord04.atlas.cogentco.com (154.54.3.42)  235.082 ms  235.106 ms  234.924 ms
16  g3-2.hc01.ord04.atlas.cogentco.com (204.6.150.34)  235.012 ms  235.066 ms  235.036 ms
17  StardockCorporation.demarc.cogentco.com (38.112.15.250)  234.916 ms  234.771 ms  234.756 ms
18  66.28.242.201 (66.28.242.201)  234.784 ms  236.982 ms  234.748 ms

From the UK...

Pinging 66.28.242.201 with 32 bytes of data:

Reply from 66.28.242.201: bytes=32 time=114ms TTL=114
Reply from 66.28.242.201: bytes=32 time=115ms TTL=114
Reply from 66.28.242.201: bytes=32 time=116ms TTL=114
Reply from 66.28.242.201: bytes=32 time=115ms TTL=114

Ping statistics for 66.28.242.201:
	Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
	Minimum = 114ms, Maximum = 116ms, Average = 115ms

Pinging 67.19.42.49 with 32 bytes of data:

Reply from 67.19.42.49: bytes=32 time=164ms TTL=245
Reply from 67.19.42.49: bytes=32 time=163ms TTL=245
Reply from 67.19.42.49: bytes=32 time=161ms TTL=245
Reply from 67.19.42.49: bytes=32 time=162ms TTL=245

Ping statistics for 67.19.42.49:
	Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
	Minimum = 161ms, Maximum = 164ms, Average = 162ms

Edit: ooooo, quick edit is niiiiice

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • It wouldn't be hard for me to turn off my TV, if I had one. For one thing, I never scroll Instagram. The only reason I have an account is because Meta created one when it merged the account systems for its various services.
    • OpenAI's new GPT-5.5-Cyber tops Claude Mythos 5 in vulnerability benchmark by Pradeep Viswanathan OpenAI today announced a major expansion of Daybreak, a cybersecurity initiative designed to help defenders find, validate, and fix software vulnerabilities earlier in the development process. The availability of powerful AI models has definitely changed the cybersecurity landscape by making vulnerability discovery much faster. However, the bigger bottleneck for the industry is now patching those vulnerabilities. Impacted software teams need to validate the discovered issues, understand their impact, develop fixes, test them, and deploy patches. Back in March, OpenAI launched a preview of Codex Security, which uses agentic reasoning with automated validation to discover high-impact issues and actionable fixes specific to the codebase. Since then, it has scanned more than 30 million commits across over 30,000 codebases; more than 70,000 findings were marked as fixed by human reviewers, while over 500,000 findings were automatically determined to be fixed. Now, OpenAI is releasing an updated Codex Security plugin that can run deep scans, review recent code changes, generate security reports, trace attack paths, validate findings, and create codebase-specific patches for human review. It can also triage findings from existing scanners, advisories, bug bounty reports, and ticketing systems. OpenAI says the plugin can export results to vulnerability management systems and integrate with workflows using SARIF files, CodeQL queries, the Codex CLI, and the Codex app. Back in May, OpenAI announced the preview of GPT-5.5-Cyber, a new model built on top of the recently released GPT-5.5, designed for specialized cybersecurity work. Today, OpenAI launched the full version of GPT-5.5-Cyber through a limited release for verified defenders. On CyberGym, GPT-5.5-Cyber scored 85.6%, compared with 81.8% for GPT-5.5 and 83.8% for Claude Mythos 5. It also scored 39.5% on ExploitGym, compared with 25.95% for GPT-5.5, and 69.8% on SEC-bench Pro, compared with 63.1%. OpenAI also announced the new Daybreak Cyber Partner Program, which will allow security vendors and service providers to use GPT-5.5 with Trusted Access for Cyber in their products and services. Accenture, Akamai, Cisco, Cloudflare, CrowdStrike, IBM, Palo Alto Networks, Proofpoint, SentinelOne, Wiz, Zscaler, and others were listed as initial partners for this program. OpenAI is also launching Patch the Planet with Trail of Bits, HackerOne, Calif, researchers, and maintainers. More than 30 open-source projects have committed to participate, including cURL, Go, Python, Sigstore, and pyca/cryptography.
    • AMD confirms 26.6.2 FSR driver breaks on many Windows PCs by Sayan Sen Earlier today AMD released a major graphics driver update as it brings support for FSR 4.1 to Radeon RX 7000 series GPUs. The new update, version 26.6.2, also brings support for Assassin's Creed Black Flag Resynced and more. And while the driver technically supports Windows 10 version 21H2 and newer, the tech giant has confirmed that there is a major issue with the new driver on non-Windows 11 PCs as it fails to launch properly on such systems. The error message says, "The version of AMD Software that you have launched is not compatible with your currently installed AMD graphics driver." Therefore on the surface it looks like a compatibility problem. AMD has also confirmed that the device manager will display the yellow bang or yellow exclamation sign alongside your GPU under the Display adapters dropdown. Here is what the Radeon team's official advisory recommends to affected users: "Users Running Windows 10 and AMD Software: Adrenalin Edition 26.6.2 May Encounter Yellow Bang in Device Manager Affecting AMD Radeon RX Series Graphics ... Our Engineers are currently investigating this issue and will provide a fix once it is available. Affected users may revert to AMD Software: Adrenalin Edition 26.6.1 as a temporary workaround." As such you should revert back to the previous 26.6.1 driver which was released earlier this month. In case you were looking to play Assassin's Creed Black Flag Resynced and DOOM: The Dark Ages | Revelations you will probably have to wait a while if you want the driver to support those games officially. You can find the support article here on Microsoft's website.
    • https://uupdump.net/selectlang...7829-4524-978d-7b5fe79263e3
    • A McDonald's restaurant uses about 1.5 to 2 million gallons of water per year for operations like food preparation, cleaning, and restrooms. That is a lot less than the 2,083 gallons of water per megawatt hour mentioned above.
  • Recent Achievements

    • Week One Done
      Almohandis earned a badge
      Week One Done
    • Rookie
      dorf went up a rank
      Rookie
    • First Post
      mike_rumble earned a badge
      First Post
    • Dedicated
      tuben earned a badge
      Dedicated
    • Week One Done
      mnsgroup earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      505
    2. 2
      +Edouard
      208
    3. 3
      PsYcHoKiLLa
      100
    4. 4
      Michael Scrip
      88
    5. 5
      neufuse
      71
  • Tell a friend

    Love Neowin? Tell a friend!