10 days of radio silence? What's going on? anyway benchmarks (countsey of
bench.sh ) of the server/bandwidth

-------------------- A Bench.sh Script By Teddysun -------------------
 Version            : v2022-06-01
 Usage              : wget -qO- bench.sh | bash
----------------------------------------------------------------------
 CPU Model          : Intel(R) Xeon(R) CPU E7- 4870  @ 2.40GHz
 CPU Cores          : 40 @ 2524.597 MHz
 CPU Cache          : 30720 KB
 AES-NI             : Enabled
 VM-x/AMD-V         : Enabled
 Total Disk         : 393.6 GB (48.7 GB Used)
 Total Mem          : 125.9 GB (12.0 GB Used)
 Total Swap         : 8.0 GB (0 Used)
 System uptime      : 10 days, 2 hour 11 min
 Load average       : 40.18, 40.10, 40.13
 OS                 : Ubuntu 20.04.4 LTS
 Arch               : x86_64 (64 Bit)
 Kernel             : 5.4.0-122-generic
 TCP CC             : cubic
 Virtualization     : Dedicated
 Organization       : AS31798 DataCity
 Location           : Kitchener / CA
 Region             : Ontario
----------------------------------------------------------------------
 I/O Speed(1st run) : 812 MB/s
 I/O Speed(2nd run) : 841 MB/s
 I/O Speed(3rd run) : 821 MB/s
 I/O Speed(average) : 824.7 MB/s
----------------------------------------------------------------------
 Node Name        Upload Speed      Download Speed      Latency
 Speedtest.net    941.15 Mbps       829.87 Mbps         3.09 ms
 Los Angeles, US  937.01 Mbps       903.15 Mbps         64.21 ms
 Dallas, US       941.23 Mbps       898.69 Mbps         36.36 ms
 Montreal, CA     888.80 Mbps       916.91 Mbps         11.09 ms
 Paris, FR        886.36 Mbps       820.77 Mbps         90.50 ms
 Amsterdam, NL    854.88 Mbps       770.73 Mbps         98.16 ms
 Shanghai, CN     426.16 Mbps       833.23 Mbps         216.21 ms
 Nanjing, CN      439.53 Mbps       542.91 Mbps         198.60 ms
 Seoul, KR        465.37 Mbps       367.20 Mbps         216.88 ms
 Singapore, SG    417.93 Mbps       132.76 Mbps         212.71 ms
 Tokyo, JP        668.62 Mbps       676.35 Mbps         134.48 ms
----------------------------------------------------------------------
 Finished in        : 5 min 35 sec
 Timestamp          : 2022-07-22 21:35:37 UTC
----------------------------------------------------------------------

- it incorrectly says 393GB because of partitioning, it's actually 1TB

- I've intentionally disabled Hyperthreading because... in my
opinion/experience, hyperthreading implementations in older Intel CPUs
often did more harm than good, making the cpus run hotter and clock lower,
this is a (high-end) 2011 model. (I have the opposite experience with AMD
SMT fwiw)



On Thu, 14 Jul 2022 at 01:18, Hans Henrik Bergan <divinit...@gmail.com>
wrote:

> Fwiw Chris Haas / vendiadvertising.com has reached out, they're willing
> to sponsor raid(1) if my proposal is accepted.
> Haas is reading this mailing list, but does not wish to participate/post
> directly at present.
> (I have no prior relation, never heard of them before today)
>
> On Tue, 12 Jul 2022 at 22:31, Hans Henrik Bergan <divinit...@gmail.com>
> wrote:
>
>> i have a 40-core 128GB RAM server with 1 (and only 1) static ipv4 address
>> that I intend to keep around until at least 27 november 2025 (but unsure
>> after that),
>> it has more RAM/CPU than i need, and i could set up a virtual machine on
>> it and give VNC access to the VM in the form of
>> > ssh -L 9999:localhost:3389 user@ip
>> then point a RDP/VNC client to localhost:9999
>> i can dedicate individual TCP ports to it, but not any of 22, 80, 443,
>> 5900,  5901, 8083, 9999, 587, 2525
>> (after which i can recommend Teamviewer for a more comfortable access)
>>
>> but the server has several caveats:
>> - it's un-raided, rolling just a single 1TB SSD, if that SSD was to die,
>> everything on it would be lost, and it would probably take days to replace
>> the drive.
>> - it's located in a somewhat unstable environment, occasional power
>> outage, it was out on 30 june, 23 june, 27 january, and in 2021 was down on
>> 30 august. (it boots up and recovers automatically, but it has a reboot
>> time of roughly 300 seconds until ssh responds again)
>> - I can not offer a dedicated IP (but can offer some dedicated ports)
>> - May be decommissioned after 27-11-2025
>>
>> If that sounds like a good idea, I'll want a ssh public key.
>>
>>
>> On Tue, 12 Jul 2022 at 15:38, Christoph M. Becker <cmbecke...@gmx.de>
>> wrote:
>>
>>> On 11.07.2022 at 21:04, Hans Henrik Bergan wrote:
>>>
>>> > Any of you windows.php.net guys familiar with SSH? Can one be created?
>>>
>>> That would be possible (needed to be set-up by Alex Schoenmaker), but
>>> while that could solve the upload issue, it wouldn't solve the other
>>> issue I've mentioned, namely that we need to avoid dynamically linking
>>> against incompatible versions of dependencies.  And there is yet another
>>> issue, namely security.  I think these issues can only be solved by some
>>> central place where the packages are build.
>>>
>>> > On Mon, 11 Jul 2022 at 19:52, Christoph M. Becker <cmbecke...@gmx.de>
>>> wrote:
>>> >
>>> >> On 11.07.2022 at 18:53, Hans Henrik Bergan wrote:
>>> >>
>>> >>> Is there any SSH public key associated with the Windows php
>>> developers?
>>> >> Or
>>> >>> with CMB?
>>> >>
>>> >> No.  At least not regarding windows.php.net.
>>> >>
>>> >>> On Mon, 11 Jul 2022 at 18:25, Christoph M. Becker <cmbecke...@gmx.de
>>> >
>>> >> wrote:
>>> >>>
>>> >>>> On 11.07.2022 at 17:41, Hans Henrik Bergan wrote:
>>> >>>>
>>> >>>>> Do you mean it is unlikely that Github Actions will suffice?
>>> because
>>> >> that
>>> >>>>> would definitely be a great solution if it was possible/feasible .
>>> >>>>
>>> >>>> No.  It is only unlikely that automated uploads to window.php.net
>>> will
>>> >>>> ever be possible using GH actions.
>>> >>>>
>>> >>>>> Anyway, with regards to "I don't think there are special
>>> requirements
>>> >>>>> regarding the hardware", can you give a rough estimate on RAM/disk
>>> >> space
>>> >>>>> requirements?
>>> >>>>
>>> >>>> The old machine had something like 4 or 8 GB RAM, and a 128 GB hard
>>> >> disk.
>>> >>>>
>>> >>>
>>> >>
>>> >
>>>
>>>

Reply via email to