Re: 64-bit amd64 : actual memory limitations?
On 2014-10-28 13:27, Артур Истомин wrote:
On Sun, Oct 26, 2014 at 09:12:14PM -0400, Predrag Punosevac wrote:
On Sun, Oct 26, 2014 at 12:02 PM, Mayuresh Kathe mayur...@devio.us
wrote:
64-bit supposedly supports upto 16 exabytes of memory ('ram').
would such large capacities actually be possible to ue with
openbsd for amd64 architecture?
use-case: working with large in-memory storage for financial applications.
Check for my posts from October or November of last year for dmesg of
machine with 256 GB or RAM and 64 CPUs which ended as a computing node
running Red Hat. I have several computing nodes with 512 GB or RAM in
the lab running Red Hat. if any of them crashes I will use live USB
and
send dmesg.
I am interesting what the purpose of such machines. Science? Commercial
usage?
Also, mundane software like firefox, libreoffice or somethink else
experience any abnormal behaviour on such abnormal hardware? Of
course
if you tested it.
Thanks.
Machines with that amount of ram is not uncommon in hpc.
For what it's worth, I have in my DC about 700 nodes fitted with 256GB
of ram.
The only limitation to putting more in it is actually the price and
availability of higher density modules.
Because in such system where each compute node is a 1U or half U server,
you won't usually be able to fit more than 16 modules in each.
With the comings new DDR4 module being as large as 128GB we will
eventually see 1U servers fitting more that 1TB of ram.
Re: Change routing tables when ISP goes down
Or you can use a static route to force reaching the ip from an interface. Would be more secure than bringing down a working interface just to check if another one is working ... Cheers, Louis On 2014-10-02 17:09, Stuart Henderson wrote: On 2014-10-02, Jeff j...@usedmoviefinder.com wrote: Thanks to everyone for your help/suggestions. I think that I'm headed in the right direction. I still can't seem to force a ping through a particular interface, even when I have both interfaces as default routes (I've tried both with and without mpath). If it matters, in both cases I used a lower priority (higher #) for our low speed metered connection. Here's my current routing information: default10.150.228.105 UGS5 168287 - 8 fxp0 default192.168.243.1 UGS00 - 16 fxp1 and ping -I 192.168.243.152 8.8.4.4 still sends traffic out through fxp0. ping -I only selects the source address, not the outgoing route. (With pf route-to rules suggested by others in the thread, that choice of source address can *then* result in a different route being taken, but it's not automatic). To use your lower-priority default route, you need some way to take the first route out of action. One possibility is to use something like ifconfig fxp0 down. Another is to have some kind of periodic check that removes the prio 8 default route. There have been a few suggestions to use ifstated for this - that can work - alternatives include a simple script run from cron, or relayd has some code to handle this - check the routers section in relayd.conf(5).
Re: Change routing tables when ISP goes down
On 2014-10-01 16:10, Jeff wrote: I have a very unreliable ISP (approximately 97% uptime). Many of the times that they go down, I'm connected and can ping within their limited network, but can't get to the outside world. In these cases, I have an alternate slow speed connection that I use. Right now, I manually change the default route and use pfctl to invoke an alternate pf.conf file. I'm thinking that OpenOSPF, BIRD or one of the other routing oriented daemons might be a way to automate switching back and forth. Does anyone suggestions on effective ways to automate/manage this? Thanks! Jeff Implementing a dynamic routing protocol will ensure the switch over but would require either ISP cooperation or a server on the internet side. the easiest way to achieve what you want is scripting default route change. Something like that should do the trick. while true do route1=$(ping -I $INTERFACE_TO_ISP1 $ISP1_GATEWAY -c 1 | tail -n2 | head -1 | grep -c 1 received) route2=$(ping -I $INTERFACE_TO_ISP1 $ISP2_GATEWAY -c 1 | tail -n2 | head -1 | grep -c 1 received) routa=$(ip route | grep default | cut -d' ' -f3 | tr -d ' ') if [ $route1 != 1 ] then route del default route add default gw $ISP2_GATEWAY else if [ $routa != $ISP1_GATEWAY ] then route del default route add default gw $ISP1_GATEWAY fi fi sleep $waittime //you may want to wait a bit between checks done Regards Louis
Re: VPLS and PWE3 status in Openbsd
Le jeudi 7 août 2014 23:28:37, Renato Westphal a écrit : 2014-08-05 9:17 GMT-03:00 Rafael Zalamena rzalam...@gmail.com: On Tue, Aug 05, 2014 at 12:53:43PM +0200, Alucard wrote: Hi, What is the status of VPLS/PWE3 support on Openbsd right now ? I have been researching a bit but cannot find a definitive answer. There is several mentions of work on this on the web and in the mailing lists but nothing really clear. Back in 2011 Claudio Jeker about Openbsd 4.9/5.0 state that these features are expected in near future. http://2011.eurobsdcon.org/papers/jeker/MPLS.pdf There is a couple of guys speaking about work on this on the mailing list in 2012 and 2013 http://comments.gmane.org/gmane.os.openbsd.tech/29882 http://openbsd.7691.n7.nabble.com/RFC-Patches-for-the-LDP-daemon-td228828.html But I didn't find mentions of this in the ldpd manpage (or am I missing something ?) Thank you Hi Alucard, I stopped coding VPLS/PWE3 support at the end of 2012 because it was getting messy and I didn't have time to properly write it (also I wasn't experienced enough). So after I finished my final paper which was the main reason why I was coding it I simply left it as it was. The wire(4) driver is missing MAC learning and to make it work for my presentation I had to manually add them. The VPLS implementation in LDPd was just too messy and it took me a lot of time to understand LDPd code. Now that I understand most of the ldpd code I'm ashamed of what I did at that time. So: (1) to finish wire(4) there is still a small integration with bridge(4) MAC learning code left to be done and (2) about the VPLS code in LDPd you might have a better luck talking with renato@. Hi Alucard, There is an ongoing effort to implement these features on OpenBSD. The control plane for ldpd(8) is already done, I just need some time to polish the patches and send them for review. If you want to help with testing please let me know. As for the data plane, I'm now in touch with Rafael to support him with his implementation. He will need to change a few things in order to support both the VPWS and VPLS solutions. For example, claudio@ suggested using one virtual interface per pseudo wire and use our bridge(4) for the VPLS stuff (mac learning, flooding, ageing, etc). We hope to finish things up soon. []s Hi Renato This is good news. I would be happy to help testing Louis
VPLS and PWE3 status in Openbsd
Hi, What is the status of VPLS/PWE3 support on Openbsd right now ? I have been researching a bit but cannot find a definitive answer. There is several mentions of work on this on the web and in the mailing lists but nothing really clear. Back in 2011 Claudio Jeker about Openbsd 4.9/5.0 state that these features are expected in near future. http://2011.eurobsdcon.org/papers/jeker/MPLS.pdf There is a couple of guys speaking about work on this on the mailing list in 2012 and 2013 http://comments.gmane.org/gmane.os.openbsd.tech/29882 http://openbsd.7691.n7.nabble.com/RFC-Patches-for-the-LDP-daemon-td228828.html But I didn't find mentions of this in the ldpd manpage (or am I missing something ?) Thank you
