New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
★ VirMach ★ RYZEN ★ NVMe ★★ $8.88/YR- 384MB ★★ $21.85/YR- 2.5GB ★ Instant ★ Japan Pre-order ★ & More
This discussion has been closed.

Comments
haha
Tokyo had an issue with one package, it's being returned. The other two (and I believe one being the switch) are being delivered tomorrow after customs is handled (were supposed to be delivered today.)
We should hopefully have at least two servers up by Monday, barring further complications.
We're never going to restrict users of a specific region.* With that being said, we already have some anti-abuse scripts for network and we're planning on expanding it to improve the network in the future.
Right now it only detects high bursts that fall in line with inbound and outbound attacks.
We already also receive data on the number of packets and will utilize that moving forward, and already do already use it to some small degree.
If you guys have any suggestions to further improve this, given the limits of our data, let me know. For example, we wouldn't collect or know what specifically the customer is doing. We would only get inbound and outbound number of packets, and data transfer rate, both ingress/egress. We can identify certain "general" use cases based on traffic patterns such as VPNs, outbound attacks, backups, but these are only educated guesses (but still guesses.) Any suggestions would have to keep the user's privacy in mind and it can only be what we can see external to the VM.
(Edit) *Adding in a disclaimer here, obviously if an entire nation is sanctioned then this changes but even in those cases it's impossible for us to identify someone's nationality, especially with VPNs.
finger crossed
Any udpate for 1TB Tokyo storage VPS?
Looks feasible as of now?
Eagerly looking forward to migrating data back from EU to JP.
This is small enough to where I'm considering sending it priority as well instead of freight, and moving forward we just do a bunch of smaller packages to Tokyo. I'll try to provide an update specific to when this is going out tonight.
I just ordered Ryzen in Seattle and installed ubuntu 20.04 but for some strange reason app I use even if it compiled fine crash with:
Auto-detected the hardware concurrency to be 2
Illegal instruction
On old virmach servers on intel it works fine, and so far had no issue on other VPS i own (ryzen, intel etc), might be also internal bug as app is not tested a lot
geekbench detect cpu as:
Identifier AuthenticAMD Family 6 Model 13 Stepping 3
@VirMach
@VirMach I have got this error two times recently
Are you counting both sucess and failed login attempts? I haven't made any failed login attempts recently.
Another possibility is that my ISP uses CGNAT, so maybe because someone on the same shared IP was messing around.
I don't have this problem with any other provider
Is there anyway to whitelist the IP for account?
Auto-detected the hardware concurrency to be 2
Illegal instruction
What's your compilation flags and CPU model? likely the code was compiled with incompatible
-march=optionSounds promising enough.
I'm assuming that's a yes for 1TB storage plan?
Small enough? You mean HDD servers?
Issue I use bazel to compile first time on dozen on vps/dedi/ryzen it just work here compiled bin crash and prebuild one on ryzen 5900x also crash
will test with: bazel build --copt=-march=native -c opt
now it works but is slower with march=native
could be quemu flag is bad i duno -c opt should be use all advenced instruction cpu report
cpuinfo report:
flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm nopl cpuid tsc_known_fr eq pni cx16 x2apic hypervisor lahf_lm 3dnowprefetch vmmcallcpuinfo show which defo is not K7 as geekscore is ok with ryzen 5xx
CPU 0: vendor_id = "AuthenticAMD" version information (1/eax): processor type = primary processor (0) family = 0x6 (6) model = 0xd (13) stepping id = 0x3 (3) extended family = 0x0 (0) extended model = 0x0 (0) (family synth) = 0x6 (6) (model synth) = 0xd (13) (simple synth) = AMD Athlon (unknown model) [K7]Is Seattle (RYZE.SEA-Z001.VMS) still having network issues? Getting ~20% packet loss regardless of region, which is practically unusable
I wonder if there are any plans for Singapore, where Green Cloud sells well.
Maybe Japan DC2 first?
Greencloud has two Japan locations.
Would like to see other Japan locations other than Tokyo and Osaka.
https://lowendtalk.com/discussion/comment/3388259/#Comment_3388259
Look like cpu flags did not passthrough correctly, eg, no avx. FYI my Seattle 768 server is on Ryzen 9 3900X. You can try compiling with the corresponding -march for 3900X.
It helps to know the exact time for that, and would help more if you provide MTR results in a ticket or private message.
I've read your post and placed an order for the SPECIAL 768 in Amsterdam. Could you please change the location to Tokyo? Thanks! @VirMach
The order number is: 9321225208
I don't think we'll be doing anything other than Tokyo, but I took a brief look and it seems like all other locations are just Telehouse, and while they show all their datacenters on a little map they made, they only have pages/links for Tokyo and Osaka.
So I wonder if anything is even offered?
And then NTT Nagoya. I wonder how difficult it would be to get other locations... there's probably a reason they're not really "big"
If you use Chrome and leave it open on the login page, this could count as well.
Thats really nice.Cant wait anymore.Is 8GB offer in stock tonight?
Nayoga is not a big deal. It's located between Tokyo and Osaka and close enough to Osaka. I'm think about Hokkaido or Fukuoka i.e. Northern and Southern Japan.
Fukuoka should be an ideal location to Korea and so is Hokkaido to Far East Russia. But you're probably right, only Tokyo (Chiba really) and Osaka (Mie really) have intercontinental submarine cables. Osaka seems to have as many if not more submarine cables to US and Southeast Asia than Tokyo.
I tried zen1,2,3 compile fail, only native works:
build --copt=-mtune=native
strange that -c opt compile it fine but when run it just crash
I guess thats max as GCC show even if its ryzen 3900x as:
gcc -Q -march=native --help=target | grep march
-march= k8-sse3
Nah, If you want to serve Korea, you would put servers in Korea, or maybe those big clouds (AWS, Azure, Google) in Japan. Other than that, Korean ISPs will randomly route them through SEA or LA
You might need to first try reinstalling with a basic template (eg, debian 8 or centos 7 in clientarea) in order to get the cpu pass-through to work. Then you can reinstall whatever os you want, either with template or iso.
Getting about ~150ms-250ms from Kansas to Seattle.
More latency than I'd get to Cloudvider in the UK for example.
Tracing route to MYIP over a maximum of 30 hops
1 3 ms 5 ms 4 ms 192.168.0.1
2 87 ms 115 ms 107 ms 10.41.224.1
3 70 ms 74 ms 75 ms 100.125.188.10
4 79 ms 78 ms 92 ms 100.120.176.4
5 86 ms 155 ms 109 ms dalsbprj02-ae1.0.rd.dl.cox.net [68.1.5.140]
6 77 ms 98 ms 71 ms 107.6.99.133
7 136 ms 108 ms 106 ms bbr1-xe-1-2-1.inapbb-chg-dal-1.chg.pnap.net [64.95.158.157]
8 175 ms 172 ms 150 ms bbr2.ae102.sef.pnap.net [64.95.158.85]
9 152 ms 175 ms 180 ms bbr1.ae7.sef.pnap.net [64.95.158.77]
10 135 ms 193 ms 162 ms core1.po2.inap-31.sea.pnap.net [64.95.158.154]
11 179 ms 145 ms 180 ms border2.ae2-bbnet2.sef.pnap.net [63.251.160.69]
12 145 ms 180 ms 212 ms dedipath-64.edge2.sef003.pnap.net [63.251.162.46]
13 143 ms 129 ms 149 ms MYIP
Trace complete.
C:\Users\user>ping MYIP
Pinging MYIP with 32 bytes of data:
Reply from MYIP: bytes=32 time=139ms TTL=55
Reply from MYIP: bytes=32 time=139ms TTL=55
Reply from MYIP: bytes=32 time=279ms TTL=55
Reply from MYIP: bytes=32 time=153ms TTL=55
hi,virmach,the server of your LAKVM26 node has been offline for a week, and the work order has not been answered. Please solve it. My server ip is 23.95.68.19*
work order!
work order!
Sorry,virmach has no work order support.
See ticket #398113. The loss has been ongoing for the past half week, and I see choppy connectivity regardless of the mtr destination