Announcement

Collapse
No announcement yet.

DragonFlyBSD Now Supports Up To 64TB Of RAM

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by Steffo View Post
    You guys should uninstall Chrome and install Firefox.
    Latest Firefox is very sluggish on my laptop (even more so than older FF versions, which were only sluggish when loading web pages, latest one is sluggish throughout the whole interface). And I do have decent 2016 specs, it was a clean FF install and the rest of my system and apps are buttery smooth, so it's not my laptop's fault.
    Last edited by Vistaus; 12-05-2017, 11:54 AM.

    Comment


    • #12
      Originally posted by Vistaus View Post
      Latest Firefox is very sluggish on my laptop (even more so than older FF versions, which were only sluggish when loading web pages, latest one is sluggish throughout the whole interface). And I do have decent 2016 specs, it was a clean FF install and the rest of my system and apps are buttery smooth, so it's not my laptop's fault.
      I think there is something wrong on your side.

      All my firefoxes (Windows and Linux, both fresh installs and ancient FF profiles updated over the years) did feel the jump to FF 57, it's much better.

      And also other people usually report better performance.

      Comment


      • #13
        Originally posted by pavlerson View Post
        No, this it not true. Can you link to any such system? SGI UV3000 is a cluster, because it only runs clustered workloads. Check the website. No one use SGI UV3000 with 10.000s of cores and 64TB RAM to run scale up business servers such as databases nor SAP. SAP Hana is for analytics, and analytics are running great in parallell. SAP Hana also runs fine on a cluster, and was made for clusters initially.

        I know of no Linux business server that has 64TB RAM. The 4096 cpu Linux servers from SGI (such as Altix, UV2000, UV1000, etc), are all clusters.
        Is this the return of Kebabbabert or are all Solaris fans this misinformed? Yes it's true that the SGI systems are clustered together by smaller hw boxes but the important part here is that the clustering is done by SGI:s low level OS that then presents it as a single system to the Linux Kernel that is the main OS on these systems. So you have a single Linux Kernel instance running on this whole cluster so this is not the HPC kind of interconnected independent machines.

        And it's done this way to support the kind of work loads that would not work particularly well on a HPC cluster (or would require a fuck ton of work to recode into a massively parallel problem).

        And if you indeed are the return of Kebabbert this is not the first time that I have told you how these systems work.

        Comment


        • #14
          Well this was about DragonFlyBSD supporting 64TB. I see comments by people claiming that "nobody" runs DragonFlyBSD. Well I don't run it , but it would be stupid to ridicule this. Some run it , and perhaps the 64TB ram limit is just the thing needed for someone else to run it too.

          DragonFlyBSD is not EVIL and it is after all a Unix like OS which we should all be glad is there. Having the idea that Linux is the only true OS is no better than the masses who think that Windows is the only true OS either. Now things have turned and Linux have practically taken over the world (except the desktop), we should all be happy that there exists alternatives and just maybe some of these alternatives will kick Linux behind some day. Progress is good and even if I don't use DragonFlyBSD myself I think it's great that it supports 64TB of ram even if "nobody" is using it! In fact I would find it even more interesting if it supported a yottabyte!

          Comment


          • #15
            Originally posted by F.Ultra View Post

            Is this the return of Kebabbabert or are all Solaris fans this misinformed? Yes it's true that the SGI systems are clustered together by smaller hw boxes but the important part here is that the clustering is done by SGI:s low level OS that then presents it as a single system to the Linux Kernel that is the main OS on these systems. So you have a single Linux Kernel instance running on this whole cluster so this is not the HPC kind of interconnected independent machines.

            And it's done this way to support the kind of work loads that would not work particularly well on a HPC cluster (or would require a fuck ton of work to recode into a massively parallel problem).

            And if you indeed are the return of Kebabbert this is not the first time that I have told you how these systems work.
            The biggest slowlaris (which is thankfully dead) troll probably thinks all those thousands of CPUs are needed to be closed under one case to be called big iron. Imagine cooling and repairing such system and how big it needs to be? What idiot denies it's single Linux kernel which sees and handles all these CPUs and memory.

            Comment


            • #16
              Originally posted by Vistaus View Post

              Latest Firefox is very sluggish on my laptop (even more so than older FF versions, which were only sluggish when loading web pages, latest one is sluggish throughout the whole interface). And I do have decent 2016 specs, it was a clean FF install and the rest of my system and apps are buttery smooth, so it's not my laptop's fault.
              You may want to check your FF settings if more than one process is enabled.

              Comment


              • #17
                Originally posted by Pawlerson View Post
                What idiot denies it's single Linux kernel which sees and handles all these CPUs and memory.
                The one who finds all their technical know-how from company (Oracle) brochures (because we all know that the PR department never lies).

                Comment


                • #18
                  Originally posted by F.Ultra View Post

                  Is this the return of Kebabbabert or are all Solaris fans this misinformed? Yes it's true that the SGI systems are clustered together by smaller hw boxes but the important part here is that the clustering is done by SGI:s low level OS that then presents it as a single system to the Linux Kernel that is the main OS on these systems. So you have a single Linux Kernel instance running on this whole cluster so this is not the HPC kind of interconnected independent machines.
                  Sorry, missed your post.

                  Are you trying to say that the large SGI system clusters (that present it as a single image by software) can run non clustered workloads?? But that is false. ScaleMP use the same approach, there is a low layer software that connects the nodes and presents it to Linux as a single image - and the performance is awful if you read people testimonies.

                  As I have explained numerous times; Scale-up servers are one beefy server using 16- or even 32-cpus. Scale-out are clusters such as SGI Altix/UV3000/... or ScaleMP with 10.000s of nodes.

                  Scale-up workloads, typically business workloads such as SAP, databases, etc serve 1000s of clients at the same time. All the clients do different things at the same time; accounting, reporting, database, etc. All the clients' workloads can never fit into cpu cache. This also means that the code branches heavily all the time, using different code paths all the time, which also cannot be predicted nor cached in CPU cache. This means that the server needs to access RAM all the time, bypassing cpu cache. And RAM is typically 100ns, which is the equivalent of 10MHz. So, when you serve 1000s of clients (which business workloads do) you have a 10MHz cpu. That is not fast. Factor in all the communication between the cpus and mutexes and locks, etc - and performance drops below 10MHz.

                  Now imagine trying to run business workloads on a scale-out cluster such as SGI UV3000. Imagine trying to reach another node, then we are not talking about 100ns but much worse. This means clusters running workloads that branch heavily, and bypasses CPU cache all the time will have much slower than 10MHz, maybe 1-2 MHz when they need to access ram in another node. And as you know, you cannot serve 1000s of clients on a 1 MHz server.

                  This is the reason that SGI/ScaleMP clusters cannot run scale-up workloads because latency to another node would be much worse than 100ns. That is the reason you need one single large beefy server, scale-up to run business workloads. Think about this a moment, and then you will understand it is true. You do know programming and are not stupid so you will agree.

                  OTOH, scale-out workloads can only run on clusters. They always serve one single user that starts up a long calculation running for weeks. The code typically solves a PDE on a small set of grids, iterating the same PDE all the time. So there is not much communication going on between the nodes. And everything can fit in the cpu cache, as the code does not branch heavily using many different code paths. And if you check SGI UV3000 customer testimonials, ALL are running heavy calculations that take weeks. There is NO ONE running business workloads on SGI clusters. Not a single story on the entire internet. Check the SAP top benchmarks, all belong to 16- or 32-cpu servers (SPARC). There is not a single cluster there.

                  Regarding topology
                  If you use say, 256 cpus as SGI Uv3000 does, then you cannot connect each cpu to each other, as that would be 256 over 2 combinations, which is 65.536 connections. No, instead you group cpus into clusters so a cpu that needs to reach another cpu, go first via cluster to next cluster and then down to cpu. That is why they are called CLUSTERS, so you get just a few connections.

                  Let us check the topology of a scale-up x86 server with 16-cpus:
                  https://deinoscloud.files.wordpress....llions-bcs.png
                  If the red cpus needs to communicate to each other, it is three hops. Each hops adds lot of latency. And this is in a single large 16-cpu server! 3 hops! Now imagine 32-cpus, that would be 4-5 hops! Even slower! We are down to 1 MHz or so.

                  Now lets look at a RISC SPARC server instead. The topology is far superior:
                  https://2eof2j3oc7is20vt9q3g7tlo5xe-...ct-370x290.jpg
                  We see that in this 32-cpu server, there is at maximum 2 hops to reach any other cpu. And this SPARC scales to 96-cpus! Look at this. Maximum 2 hops in worst case scenario:
                  https://images.techhive.com/images/i...51837-orig.jpg
                  That is the reason the top spots in the SAP benchmarks, all belong to RISC servers using SPARC. There is not a single cluster there. All servers have 32 cpus or less. No one use 10.000 of cpus for SAP. Because too many cpus impose too many hops, each adding latency.

                  Finally, do you know understand why there is not a single customer that runs business workloads on SGI UV clusters? Because it would be too slow.

                  Comment


                  • #19
                    Originally posted by pavlerson View Post
                    Sorry, missed your post.

                    Are you trying to say that the large SGI system clusters (that present it as a single image by software) can run non clustered workloads?? But that is false. ScaleMP use the same approach, there is a low layer software that connects the nodes and presents it to Linux as a single image - and the performance is awful if you read people testimonies.

                    As I have explained numerous times; Scale-up servers are one beefy server using 16- or even 32-cpus. Scale-out are clusters such as SGI Altix/UV3000/... or ScaleMP with 10.000s of nodes.

                    Scale-up workloads, typically business workloads such as SAP, databases, etc serve 1000s of clients at the same time. All the clients do different things at the same time; accounting, reporting, database, etc. All the clients' workloads can never fit into cpu cache. This also means that the code branches heavily all the time, using different code paths all the time, which also cannot be predicted nor cached in CPU cache. This means that the server needs to access RAM all the time, bypassing cpu cache. And RAM is typically 100ns, which is the equivalent of 10MHz. So, when you serve 1000s of clients (which business workloads do) you have a 10MHz cpu. That is not fast. Factor in all the communication between the cpus and mutexes and locks, etc - and performance drops below 10MHz.

                    Now imagine trying to run business workloads on a scale-out cluster such as SGI UV3000. Imagine trying to reach another node, then we are not talking about 100ns but much worse. This means clusters running workloads that branch heavily, and bypasses CPU cache all the time will have much slower than 10MHz, maybe 1-2 MHz when they need to access ram in another node. And as you know, you cannot serve 1000s of clients on a 1 MHz server.

                    This is the reason that SGI/ScaleMP clusters cannot run scale-up workloads because latency to another node would be much worse than 100ns. That is the reason you need one single large beefy server, scale-up to run business workloads. Think about this a moment, and then you will understand it is true. You do know programming and are not stupid so you will agree.

                    OTOH, scale-out workloads can only run on clusters. They always serve one single user that starts up a long calculation running for weeks. The code typically solves a PDE on a small set of grids, iterating the same PDE all the time. So there is not much communication going on between the nodes. And everything can fit in the cpu cache, as the code does not branch heavily using many different code paths. And if you check SGI UV3000 customer testimonials, ALL are running heavy calculations that take weeks. There is NO ONE running business workloads on SGI clusters. Not a single story on the entire internet. Check the SAP top benchmarks, all belong to 16- or 32-cpu servers (SPARC). There is not a single cluster there.

                    Regarding topology
                    If you use say, 256 cpus as SGI Uv3000 does, then you cannot connect each cpu to each other, as that would be 256 over 2 combinations, which is 65.536 connections. No, instead you group cpus into clusters so a cpu that needs to reach another cpu, go first via cluster to next cluster and then down to cpu. That is why they are called CLUSTERS, so you get just a few connections.

                    Let us check the topology of a scale-up x86 server with 16-cpus:
                    https://deinoscloud.files.wordpress....llions-bcs.png
                    If the red cpus needs to communicate to each other, it is three hops. Each hops adds lot of latency. And this is in a single large 16-cpu server! 3 hops! Now imagine 32-cpus, that would be 4-5 hops! Even slower! We are down to 1 MHz or so.

                    Now lets look at a RISC SPARC server instead. The topology is far superior:
                    https://2eof2j3oc7is20vt9q3g7tlo5xe-...ct-370x290.jpg
                    We see that in this 32-cpu server, there is at maximum 2 hops to reach any other cpu. And this SPARC scales to 96-cpus! Look at this. Maximum 2 hops in worst case scenario:
                    https://images.techhive.com/images/i...51837-orig.jpg
                    That is the reason the top spots in the SAP benchmarks, all belong to RISC servers using SPARC. There is not a single cluster there. All servers have 32 cpus or less. No one use 10.000 of cpus for SAP. Because too many cpus impose too many hops, each adding latency.

                    Finally, do you know understand why there is not a single customer that runs business workloads on SGI UV clusters? Because it would be too slow.
                    So you agree with what I wrote but then still somehow disagrees. Boy you really are Kebbarbert are you.

                    Comment


                    • #20
                      Originally posted by F.Ultra View Post

                      So you agree with what I wrote but then still somehow disagrees. Boy you really are Kebbarbert are you.
                      I have never agreed on this. I have always explained that a cluster can never run a workload what servers 1000s of clients because the server needs to go out to RAM all the time. And it does not matter if SGI presents all nodes as one single server to Linux using software. The latency will always be bad. Scale-up workloads maxes out at 32-cpus or so. If you go above that, latency would be too bad for commercial scale-up workloads as explained here by SGI:
                      https://www.realworldtech.com/sgi-interview/6/
                      "...However, scientific applications have very different operating characteristics from commercial applications. Typically, much of the work in scientific code is done inside loops, whereas commercial applications, such as database or ERP software are far more branch intensive. This makes the memory hierarchy more important, particularly the latency to main memory. Whether Linux can scale well with a [scale-up] workload is an open question. However, there is no doubt that with each passing month, the scalability in such environments will improve. Unfortunately, SGI has no plans to move into this market, at this point in time. However, it would be very interesting to see how the low latency Altix systems would perform with commercial workloads...."

                      I can help SGI answer this question. Apparently, Linux has something called RCU to increase scalability. The inventor of RCU talks about 200 microsecond latencies. That is much worse than 100 ns. That corresponds to 0.005 MHz. However, that is not a problem as long as you use RCU on a cluster. Because then RCU would never get triggered when you run parallell workloads. But for commercial scale-up workloads, 0.005 MHz cpus does not work.

                      So, again; Clusters can never run commercial workloads. This is explained directly by SGI. Linux clusters can never compete with SPARC/POWER/Mainframes on scale-up commercial workloads. Scale-up domain belongs exclusively to RISC and Mainframes. Linux and x86 is non existent in that arena.

                      Do you finally understand why Unix people say that Linux scales bad? They mean that Linux scales bad in scale-up workloads. Linux scales excellent on scale-out servers (clusters).

                      Comment

                      Working...
                      X